pulumi: delete-before-replace triggers delete-before-replace in all dependencies
Following up from this community Slack thread, there is a bug where:
- The user changes data in a manually-named Kubernetes
ConfigMap
, which triggers a delete-before-replace. - The user references that
ConfigMap
in aDeployment
. - Because step generator believes that any resource that is marked delete-before-replace must also have all its dependencies transitively marked delete-before-replace (specifically this line), we delete the entire
Deployment
.
This is very bad for Kubernetes. It means that changing data in a ConfigMap
can trigger a complete delete-first tear-down and rebuild of your application, including a stateful application.
The comment explaining this asserts that this is true, but I’m not really sure why it would be – why, in particular, would we need to mark resources that actually don’t need to be deleted at all, as delete-before-create?
About this issue
- Original URL
- State: closed
- Created 6 years ago
- Reactions: 1
- Comments: 37 (33 by maintainers)
@naveensrinivasan We apologize for the delay here. This is a subtle and tricky issue, so it’s taken a bit of time to discuss and design. That said, it’s in our current sprint, and we will be acting on this soon. Expect a more detailed update tomorrow on the plans and timeframe on a fix.
The PR for this is in progress at https://github.com/pulumi/pulumi/pull/2369. Currently expecting this to be available next week (hopefully early next week).
Great! We are being blocked by the EKS issue referred here.
This may not in fact be TF’s behavior. Consider the following config:
If I deploy this, then change the name of the first bucket, then run an
apply
, the second bucket is not replaced:I also don’t know whether you’d want to let a resource make a decision about its dependents. In general, this would seem to be something that only those dependents would be qualified to decide.