Hi everyone, I am using Component Resources in my code. In my scenario, I create a security group rule as part of this component resource. The effect of renaming the resource is to create a new resource and delete the old one. The order seems to be to create the new resource first then delete the old one. Unfortunately, you cannot have duplicate security group rules therefore I have a question: • Is there a way I can force deletion first ? (this is not a scenario for

deleteBeforeReplace

because the renaming action results in a new resource to be created) Thanks!

Security group rules should need to be deleted only if the rule name now refers to a new rule. For example, if you have "my-rule-1" that is ingress port 443 from 0.0.0.0,. Then you add a new rule, and have "my-rule-2" that is ingress port 443 from 0.0.0.0 and now "my-rule-1" is ingress port 8443 from 0.0.0.0, then "my-rule-1" will be deleted and recreated. If this describes your problem, then you need to find a way to not rename the rules like this. For example, don't use array indices or some sort of ordinality in the name of the rule. Instead, use the properties of the rule. If the first rule had be called "my-in-443-0.0.0.0" then the deletion wouldn't be required, because it would still have that name after adding the new rule.

Hi, thanks for replying to my question. Let me expand on this: In my setup, I have an existing security group rule which allows traffic to port 443 from 10.1.0.0/24 and the name is derived from the name of the custom resource. If I rename the custom resource and a new one will be created in place, the rule will be the same except for the name (description) which will obviously be different. If I am to try the same action from the AWS Console I get this (which makes sense because the destination port and the source CIDR is the same, regardless of the rule name). Therefore the main question is: how can I tell pulumi to "taint" the resource ? P.S: I use pulumi automation API. Thanks

To taint, you can either manually delete the resource then refresh (ick), or force Pulumi to do exactly that, by commenting out the code, running

pulumi up

, then uncommenting and repeating. Neither is good. The alternative is to not rename the resource, and just change the values. This may result in a badly-named resource. This is an unfortunate side effect of having managed resources that do not have their own cloud ID. It is on you to ensure that the Pulumi name does not change, or does change, depending on your particular use case. Security group rules are not the only resource with this problem. NACL rules are very similar. And they're slightly worse, because it looks like they have an ID (the rule number), but in fact they don't, the number is just another property. You may find you simply have to delete some things manually this time, in order to fix the naming so that it will never be needed in the future. That was what I had to do.. more than once.

heh, yeah, deleting it manually is what I am doing now but obviously not something I want to deal with, thanks for taking your time on this! appreciate it!

It is possible to force dependencies from one rule to another, which may force deletion in the order you need. I can't think of exactly how this might work (not at my computer), and it may still require two `pulumi up`s to work. But it is something to consider.

Curious if you could elaborate a little bit on the NACL issue? On the surface this kind of issue with an unexpected Create,Delete plan looks very similar to https://github.com/pulumi/pulumi-aws/issues/1923 but there might be a pattern spanning many AWS resources.. I'm trying to collect the use cases so we can find a good solution in Pulumi for this

The NACL rule issue can be recreated by creating rules in a loop from a map or dict, with the rule number as the key. Swap the values of two rules. In theory, this can be done without delete/create, but Pulumi can't manage it in a single update, because updating either rule makes it conflict with the other.

Do you have a quick example program? Much appreciated.

Not right now, as I've fixed the problem. It's always avoidable: the problem happens when the programmer tries to be helpful and work out rule numbers, and then the order of rules changes (in a config file or whatever). It can be avoided by recognizing that rule numbers are a property, and requiring them in whatever data you're generating the rule-creating code from. It's just something that bit me a few years ago. You can recreate the problem without a loop. Just create two rules,

pulumi up

, then swap the rule numbers of the two rules and

pulumi up

. This exposes the bug. (It's not a Pulumi bug, it would have been a bug in the code that created the rules in a loop).