fix(infra): cdk destroy of the Fargate stack fails when the last blue/green deploy left green live
Les mainteneurs répondent en général sous 1 jour
Personne n'a encore pris cette issue.
Évaluation
- Difficulté
- 3/5
- Temps estimé
- 1-2 jours
- Accessibilité débutants
- 55/100
- Type d'issue
- Bug
- Clarté
- Clairement spécifiée
- Activité
- Active
- Stack technique
- aws, python
- Domaine
- cloud, infrastructure
Piste de recherche
Start in infrastructure/cdk/stacks/fargate_service_stack.py, where the listener rules (https_listener.add_target_groups(...)) and the TestListener are defined, and check which target groups each one depends on. Make every rule and the TestListener depend on both blue and green target groups using node.add_dependency, then add a synth test that asserts the DependsOn entries. Done when cdk synth shows the dependencies and the docs/self-hosting/cdk.md 'Tearing an environment down' section covers the interim workaround.
Rédigé par le modèle d'indexation à partir du texte de l'issue.
Description
cdk destroy experimentation-fargate-<env> fails with DELETE_FAILED on the green target group ("target group ... is currently in use by a listener") whenever the last blue/green deployment left the live listener rules pointing at green.
Why: CodeDeploy's blue/green deployment moves the HTTPS listener's rules between the blue and green target groups outside CloudFormation. After an odd number of deployments the rules point at green, while the template still describes the rules the stack created. In infrastructure/cdk/stacks/fargate_service_stack.py neither the listener rules (https_listener.add_target_groups(...)) nor the TestListener declare a dependency on both target groups (there is no add_dependency / DependsOn between them), so CloudFormation may delete the green target group before the rules and the listener that still use it. The rest of the stack is deleted; a second cdk destroy then succeeds. This is deterministic, not a race.
Expected: cdk destroy succeeds in one run whatever target group is live.
Fix: make every listener rule and the TestListener depend on BOTH target groups (node.add_dependency on each), so CloudFormation deletes the rules and listeners before either target group; pin it with a synth test that asserts the DependsOn entries. Until it ships, docs/self-hosting/cdk.md's "Tearing an environment down" section should say: if the Fargate stack's delete fails with "in use by a listener", run cdk destroy for that stack again.
Found while tearing down a test environment. Priority is set in the pre-launch bug triage.
- Langage dominant
- Python
- Étoiles
- 0
- Forks
- 4
- Merge moyen
- 7 h 47 min
- PR mergées (30 j)
- 427
Préparer son environnement
- Fournit un Dockerfile ou un fichier Docker Compose
- Propose un modèle de pull request
- Lire le guide de contribution
Par où commencer
- Lisez l'issue en entier, puis le guide de contribution du projet.
- Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
- Forkez le dépôt et travaillez sur une branche.
- Ouvrez une pull request qui référence le numéro de l'issue.
Autres issues de Controlvar/controlvar
-
bug post-launch
Difficulté 2/5 1-3 heures Accessibilité débutants 76/100
Controlvar/controlvar#1818 ·
Les mainteneurs répondent en général sous 1 jour
-
bug
Difficulté 2/5 1-3 heures Accessibilité débutants 82/100
Controlvar/controlvar#1813 ·
Les mainteneurs répondent en général sous 1 jour
-
bug
Difficulté 1/5 1-3 heures Accessibilité débutants 88/100
Controlvar/controlvar#1806 ·
Les mainteneurs répondent en général sous 1 jour
-
Difficulté 2/5 1-3 heures Accessibilité débutants 90/100
Controlvar/controlvar#1447 · 2 commentaires ·
Les mainteneurs répondent en général sous 1 jour
-
enhancement post-launch
Difficulté 2/5 1-3 heures Accessibilité débutants 72/100
Controlvar/controlvar#1042 ·
Les mainteneurs répondent en général sous 1 jour
Toutes les issues de Controlvar/controlvar
Issues similaires
-
bug
Difficulté 2/5 1-3 heures Accessibilité débutants 78/100
cunla/fakeredis-py#636 ·
Les mainteneurs répondent en général sous 2 jours
-
Difficulté 2/5 1-3 heures Accessibilité débutants 78/100
opensafely-core/job-server#6180 · 1 commentaire ·
Les mainteneurs répondent en général sous 1 jour
-
area:models enhancement
Difficulté 2/5 1-3 heures Accessibilité débutants 76/100
Les mainteneurs répondent en général sous 1 jour
-
bug needs-triage
Difficulté 2/5 1-3 heures Accessibilité débutants 86/100
newrelic/newrelic-python-agent#1913 · 1 commentaire ·
Les mainteneurs répondent en général sous 1 jour
-
Difficulté 2/5 1-3 heures Accessibilité débutants 77/100
Les mainteneurs répondent en général sous 1 jour