wide-dress-96388
06/19/2023, 3:56 PMFileArchive <-- azure.Blob <-- k8s.Deployment <-- k8s.Service
• When a change occurs to the hash of the FileArchive
, the Blob
is marked as replace
, and that leads to a cascading replace on the K8s Deployment
and Service
• Is there a way to mark the changes (inherited) changes in the Deployment/Service as non-replacing changes (it's a safe-update), or a way to force Pulumi to make an update (instead of replace
) for the Blob
? 🤔
• The scenario above causes some downtime issues, since changing the blob changes the Deployment spec, and that leads to downtime, because sometimes Pulumi just replaces the original K8s Deployment
in a non-graceful way 😞 (we see that it deletes and only then creates a new Deployment)
Thanks 🙂acceptable-intern-25844
06/19/2023, 8:35 PMDocker.Image
. It first removes the deployment, then waits a minute while the image is being built, and only then creates a new deployment.Docker.Image
like new Docker.Image(serviceName+':'+serviceVersion)
.If I update the version - pulumi decides to create a new image first, and then update the deployment. But if the version is the same as the previous one and the context hash digest is changed - it decides to remove the deployment first, and then build and recreate the deploymentwide-dress-96388
06/20/2023, 6:33 AMacceptable-intern-25844
06/20/2023, 10:16 AMreplaceOnChanges
option, looks like it is the opposite of what we want. The only way to deal with accidental deletes is the protect
resource option, which throws an error if some state diff results in replacement. With this, we could at least figure out exactly which changes are not updatable. Also there are fields that always trigger the replacement, in case of Deployment check the docs and search on the page for: Cannot be updated
.protect
allows the replacement…wide-dress-96388
06/20/2023, 1:36 PM