I've been having some issues with the

propagateTags

property from the aws.ecs.Service: 1. setting it's value for the first time triggers a Service create-replacement. 2. changing it afterwards also triggers a Service create-replacement. The pulumi up detail shows the

name

,

id

and

propagateTags

changing. The

name

and

id

change is due to the ending randomId from pulumi changing. Tried TASK_DEFINITION, SERVICE, NONE and removing the property, it always requires a replacement. I understand that changing the name triggers a replacement but why does

propagateTags

change the ending randomId from

name

? Has anyone had this issue?

Hi Theo. I went to the documentation to check out the

propagateTags

field. I noticed it doesn’t have the “replace-on-change” icon (see screenshot). So changing the

propagateTags

field by itself shouldn’t cause a replacement (if it does, something’s buggy). But I think the actual issue is a little different. Can you try setting the

name

field to a string literal? I suspect you’re not setting the

name

field yourself each time, so Pulumi generates a random name. Since that random name is different from the randomly generated name from the prior run, the engine detects a difference between the old and the new name, on a property that requires a

replaceOnChange

(the name property). That’s why you’ll recreate the Service each time. That’s my guess at the cause of your issue. I’m pretty new to Pulumi myself, so I apologize if I’m directing you down the wrong path! But you might want to give that a go 😄

I also saw the

replace-on-change

icon and I agree that changing other properties that don't have it does not trigger a create-replacement. Changing

propagateTags

by itself though triggers a replacement (and as you said, it doesn't have the icon). Is this a known bug then? If this is something we must accept (due to inner pulumi workings), could a

replace-on-change

icon be added here as well?

I’m under the impression it’s more likely due to the

name

field being unset as I mentioned above. Have you tried providing a string literal to set the

name

of the ECS Service? Or could you provide a redacted code snippet? If it’s true that the error is actually with

propagateTags

, then yes, that would most likely be a bug for a missing icon. Pulumi doesn’t determine which properties are

replace-on-change

and which aren’t. I believe that’s determined by AWS, and part of their public API. I’m still more keen on the

name

theory myself 🙂

Are you also changing the name parameter to the constructor? That will always cause a replacement, because as far as Pulumi in concerned, that's an entirely new resource. You need to keep the constructor's 1st parameter (name) the same.

Sorry for the long delay, for the sake of the experiment I specified the "name" property on the fargate service and now I can clearly state that changing "propagateTags" will trigger a create-replacement even if the name is not changing in the details output.

The name property in the 2nd parameter (args) shouldn't cause this problem, even if it's not provided. Pulumi won't generate a new value each time. It will generate a new value only if it knows it is doing a replace. The first parameter is the one that needs to not change. This is the Pulumi name.

@little-cartoon-10569 the first name (not the one in the args) has always been hardcoded

FYI i’ve submitted a bug issue on github for this https://github.com/pulumi/pulumi-aws/issues/2082