https://pulumi.com
Join Slack
This message was deleted.
# general
s
This message was deleted.
➕ 1
a
just noticed the same but with 
Docker.Image
. It first removes the deployment, then waits a minute while the image is being built, and only then creates a new deployment.
one more notice: I have the service’s version in the resource name of the 
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 deployment
w
Yeah I feel it's a very similar issue. Some resource cascaded their "replace" state into their dependencies, even when it does not make sense (for things like Deployment)
a
Well, I have read a lot of issues and it seems there is no way to control the update vs replace behavior yet. Though there is a 
replaceOnChanges
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
.
Nope, just tested, 
protect
allows the replacement…
w
Yeah 😞
Open in Slack
PreviousNext
Powered by

Pulumi Community

No matter how you like to participate in developer communities, Pulumi wants to meet you there. If you want to meet other Pulumi users to share use-cases and best practices, contribute code or documentation, see us at an event, or just tell a story about something cool you did with Pulumi, you are part of our community.

Powered by