stackabletech / stackabletech/documentation

Create ADR on options for an operator to manage stackable components

Abierto
#271 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Lenguaje dominante
CSS
Estrellas
13
Forks
14
Merge medio
4 d 8 h
PR fusionados (30 d)
10

Descripción

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

Guía de contribución

No hay ninguna guía de contribución indexada para este repositorio

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Línea de trabajo

Comienza revisando la discusión de OpenShift Slack y los cuatro enfoques propuestos; después, inspecciona los ADRs existentes en el repositorio de documentación para conocer la estructura esperada y el proceso de aprobación. Evalúa las opciones para la certificación de OpenShift y un Stackable operator más amplio, y considera el trabajo completo cuando un ADR haya sido aprobado y fusionado, se haya elegido una opción y se hayan creado tickets de seguimiento.

Escrito por el modelo de indexación a partir del texto del issue.

Evaluación

Stack tecnológico
kubernetes
Área
devops, documentation, infrastructure
Tipo de issue
Documentación
Dificultad
5/5
Tiempo estimado
Más de una semana
Estado de actividad
Estancado
Claridad
Bastante claro
Aptitud para principiantes
25/100

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.