Pulumi should automatically deleteBeforeReplace when it is required

[nesl247]

There are certain resources, such as GlobalAddress, VPNTunnel, etc. that have certain properties that require them to be replaced rather than updated. When this occurs, Pulumi should automatically deleteBeforeReplace rather than requiring the user to add deleteBeforeReplace: true. This is because it is the job of Pulumi to automatically handle all of this, and should not be on the user to know which properties cause which resources to need this, and then have to remove the flag after.

My suggestion would be to introduce a warning when this occurs as I am pretty sure the reason this isn't done today is that it could cause downtime. However, if the user is accepting the changes, it should execute as expected rather than breaking and requiring manual intervention.

[lukehoban]

Could you share an example of a specific resource and change to that resource where you think we should default to delete-before-replace?

[nesl247]

With the VPNTunnel the localTrafficSelectors property should cause delete-before-replace.

[NinoFloris]

With GKE private clusters the cluster gets into a terminal state if you don't do delete before replace.
That's because it'll notice a peering range overlap for the master ip cidr range.

[hermanbanken]

Same for IAM members. I'm seeing those getting "import-replace", where they are first replaced in the stack and then "delete-original" runs, which effectively deletes it from the Project IAM 🤦 , leaving you with a stack where they exist. Only way to fix that is refresh + up again.

[lukehoban]

I'm seeing those getting "import-replace",

Are these resources you brought in via pulumi import?

Same for IAM members.

Do you mean specifically UserGroupMembership or GroupMembership? A few other IAM resources are already marked as DeleteBeforeReplace: true by default, and I suspect you are right that these should be as well.

[hermanbanken]

We import them via importId because we are talking about around 30 resources (per stack instance, of which we currently have 4) and don't want to do this by hand.

Both the resource urn format and the import id are not easily guessable, so writing that in code (where it can be documented) is much preferred over telling users to do it using the cli.

I was talking about project.IAMMember. As it is giving us much headaches I'm gonna try to use IAMPolicy instead tomorrow.

Downside of that is that we need to load the existing user roles (vs the SA roles we're trying to manage) and merge them via code. That additional code complexity is much preferable over unexpected / works-on-your-machine-but-not-on-mine bugs. Sadly.

Will try to keep you guys posted whether that fixes our issues or if it has similar issues.

[jcalderin]

@hermanbanken 3 years later... im suffering this IAMMember. Did you end up using policies? I want to avoid that, but i guess the real problem is that when delete-original of member is deleting everything, could be a bug?