Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

Create ADR on options for an operator to manage stackable components

Ouverte
#271 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Personne n'a encore pris cette issue.

Évaluation

Difficulté
5/5
Temps estimé
Plus d'une semaine
Accessibilité débutants
25/100
Type d'issue
Documentation
Clarté
Plutôt claire
Activité
À l'abandon
Stack technique
kubernetes
Domaine
devops, documentation, infrastructure

Piste de recherche

Commencez par examiner la discussion OpenShift Slack et les quatre approches proposées, puis inspectez les ADRs existants dans le dépôt de documentation afin de comprendre la structure attendue et le processus d’approbation. Évaluez les options pour la certification OpenShift et un Stackable operator plus large, et considérez le travail comme terminé lorsqu’un ADR est approuvé et fusionné, qu’une option est choisie et que des tickets de suivi sont créés.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

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
Langage dominant
CSS
Étoiles
13
Forks
14
Merge moyen
4 j 8 h
PR mergées (30 j)
10

Guide de contribution

Aucun guide de contribution indexé pour ce dépôt

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de stackabletech/documentation

Toutes les issues de stackabletech/documentation

Issues similaires

Plus d'issues DevOps

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.