stackabletech / stackabletech/documentation

Create ADR on options for an operator to manage stackable components

Aberta
#271 0 comentários 0 reações 0 responsáveis Ver no GitHub

Ninguém assumiu esta issue ainda.

Linguagem predominante
CSS
Estrelas
13
Forks
14
Merge médio
4d 8h
PRs com merge (30d)
10

Descrição

This was triggered to a certain extent by a discussion around OpenShift and how we cannot currently certify the secret and listener operator, because these need to be deployed a a DaemonSet, which is not supported by Operator Lifecycle Manager.

The best practice / workaround here seems to be to create an operator which in turn deploys the necessary DaemonSets and then certify that operator - which in turns allows us to specify this as a dependency for the rest of our operators.
We had similar discussions a while ago / the topic comes up every now and then, whether we want a stackable operator that is in charge of updating our components / internal configmaps etc. Sort of like a k8s internal stackablectl.

I think it is worth writing an ADR and evaluating the various options that we have to
a) solve the concrete matter of getting secret and listener operator OpenShift certifiable
b) look at this from a bit further away and consider if we need a stackable operator

We briefly discussed this in the openshift slack channel: https://stackable-workspace.slack.com/archives/C03DGUK815E/p1662631718184049 and came up with these options as an initial list (there will probably be more, this is not a conclusive list):

  1. Have Stackable operator that works somewhat analogue to stackablectl but from inside the cluster
  2. Create an operator specifically for openshift to become compliant, leave everything else as is
  3. Rework secret and listener operator minimally to simply deploy one pod which then in turn deploys the daemonset
  4. 3 but have that "one pod" be the commons operator

This is done when:

  • The ADR is approved and merged and an option was chosen
  • Follow up tickets for the chosen option have been created

Guia de contribuição

Nenhum guia de contribuição indexado para este repositório

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Direção de pesquisa

Comece revisando a discussão do OpenShift Slack e as quatro abordagens propostas; em seguida, inspecione os ADRs existentes no repositório de documentação para entender a estrutura esperada e o processo de aprovação. Avalie as opções para a certificação do OpenShift e para um Stackable operator mais amplo, e considere o trabalho concluído quando um ADR for aprovado e integrado, uma opção for escolhida e tickets de acompanhamento forem criados.

Escrita pelo modelo de indexação a partir do texto da issue.

Avaliação

Stack de tecnologia
kubernetes
Domínio
devops, documentation, infrastructure
Tipo de issue
Documentação
Dificuldade
5/5
Tempo estimado
Mais de uma semana
Status de atividade
Estagnada
Clareza
Razoavelmente clara
Facilidade para iniciantes
25/100

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.