Make load balancer names collision-proof
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 4/5
- Tempo stimato
- 3-5 giorni
- Idoneità per principianti
- 55/100
- Tipo di issue
- Bug
- Chiarezza
- Abbastanza chiara
- Stato di attività
- Tranquilla
- Stack tecnologico
- go, kubernetes
- Ambito
- cloud, infrastructure
Direzione di ricerca
Inizia in internal/provider/load_balancer.go, in GetLoadBalancerName, e confronta la sua logica di denominazione con l’upstream cloudprovider.DefaultLoadBalancerName idiom. Definisci come il service UID suffix preserva l’unicità dopo il troncamento, quindi documenta un percorso di migrazione oppure una ricerca di compatibilità per le floating IP esistenti. Il lavoro è completato quando nomi di servizio troncati in modo identico ricevono floating IP distinte senza lasciare orfane quelle esistenti.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
Context
GetLoadBalancerName (internal/provider/load_balancer.go) builds cluster-namespace-service and truncates at 63 chars. Two long-named services can truncate to the identical name and end up sharing one floating IP — each reconcile loop steals it from the other, silently.
Scope
Add a suffix derived from the service UID (the upstream cloudprovider.DefaultLoadBalancerName idiom) so truncated names remain unique.
⚠️ This changes the computed name for existing floating IPs. Include a migration note or a name-compatibility lookup in the design so existing services don't orphan their floating IPs on upgrade.
Done when
Two services whose composite names truncate identically get distinct floating IPs, with a documented upgrade path.
Related: ownership verification before delete (ships best in the same release, single migration note).
- Lingua principale
- Go
- Stelle
- 6
- Fork
- 2
- Merge medio
- 3h
- PR unite (30g)
- 6
Preparare l'ambiente
Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di oxidecomputer/oxide-cloud-controller-manager
-
Documentation Kubernetes Cloud Controller Manager (CCM)
Difficoltà 2/5 1-3 ore Idoneità per principianti 74/100
-
Documentation Kubernetes Cloud Controller Manager (CCM)
Difficoltà 2/5 1-3 ore Idoneità per principianti 90/100
-
Bug Kubernetes Cloud Controller Manager (CCM)
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
-
Bug Kubernetes Cloud Controller Manager (CCM)
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
oxidecomputer/oxide-cloud-controller-manager#275 · 1 commento ·
-
Enhancement Kubernetes Cloud Controller Manager (CCM)
Difficoltà 2/5 1-3 ore Idoneità per principianti 86/100
Tutte le issue di oxidecomputer/oxide-cloud-controller-manager
Issue simili
-
bug frontend good first issue
Difficoltà 2/5 1-3 ore Idoneità per principianti 86/100
I maintainer di solito rispondono entro 1 giorno
-
trust: update-propagation-directive requires developer mode while add and remove do notForse già presa @bhuvan-somisetty l’ha presa oggi. Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
I maintainer di solito rispondono entro 2 giorni
-
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 82/100
oalders/clodhopper#133 ·
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 62/100
peasant-labs/peasant#596 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
hatchet-dev/hatchet#5179 ·
I maintainer di solito rispondono entro 1 giorno