Listeners do not re-attach post deletion without podrestart

Offen
#445 0 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
4/5
Geschätzter Aufwand
3-5 Tage
Anfängerfreundlichkeit
42/100
Issue-Typ
Bug
Klarheit
Größtenteils klar
Aktivitätsstatus
Aktiv
Tech-Stack
kubernetes, python
Bereich
backend, networking

Rechercherichtung

Start by tracing how listener UIDs are assigned and how pod labels are matched to recreated listener services; the issue does not name specific files or tests. Reproduce the deletion and recreation scenario with a HiveCluster and a ClusterInternal listener, then check that the recreated service can reach the original ready pods without a pod restart.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

type/bug
Affected Stackable version

all

Current and expected behavior

Current behaviour

Assume a HiveCluster using a listener class e.g. ClusterInternal. A HiveCluster get's created with a listener discovered by label and IP provisioned by a volumeMount at the STS level.

If a Listener service gets deleted e.g. by hand or by e.g. only updating listener-operator, a new listener service gets created, the products operator does not reconcile and thus although pods are ready it fails to be reached via the fresh listener service.

Cause

Whenever a listener is recreated, it comes with a new UID. Pod's are labeled with something like listener.stackable.tech/mnt.<uid> referencing the listener UID created for this pod. Those UIDs change when a listener restarts and the pod don't. This mismatch will cause the pod being unavailable through it's listener address while becoming healthy and available

Expected behaviour

Listeners should reattach to its original pod after restart.

Possible solution

Probably something like a label which doesn't contain the UID.

Additional context

No response

Environment

No response

Would you like to work on fixing this bug?

None

Vorherrschende Sprache
Python
Sterne
9
Forks
3
Ø Merge
1 T. 6 Std.
Gemergte PRs (30 T.)
8

Entwicklungsumgebung

  • Kein Dockerfile und keine Docker-Compose-Datei
  • Hat eine Pull-Request-Vorlage
  • Kein Beitragsleitfaden

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus stackabletech/listener-operator

Alle Issues in stackabletech/listener-operator

Ähnliche Issues

Weitere Issues zu Python

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.