I'm asking this here as I feel it's more of a general issue, but the example I will use is AWS, specifically the Elastic Container Service (ECS) and updating a Task Definition (TD) which uses AWS Systems Manager (SSM) parameters to store secret environment variables, as that is what I am working on. The issue is this. If I have a single stack which makes the SSM parameters the TD and the ECS service, and I decide I want to rename all the SSM parameters, I update the code to achieve this and then run

pulumi up

this will replace all the SSM parameters, make a new TD and then update the service to use the new TD. Which is great iff it all works, and works quickly. The problem is that if while some SSM parameters have been replaced, and others are in the process of being replaced, the ECS service autoscales, using the old TD then some of the parameters it needs will have been deleted and it will fail, or be poorly configured. This is exacerbated if some of the new SSM parameters fail to be created and the up fails having deleted some of the old SSM parameters. If I were doing this task by hand I would: 1. make the new SSM parameters 2. make the new TD 3. update the service to use the new TD 4. check the service was working 5. delete the old SSM parameters. But that is not the order in which pulumi will do it. I could rm the old SSM parameters from the stack and then delete them by hand, but that seems klunky. I could write code to make both sets of parameters, to make the new ones, then change the stack again to use the new ones and then again to delete the old ones. 🤔 maybe that's the way?

check the service was working

I suspect this is the step that is different between what you describe doing manually, and what Pulumi does by default. If you use

waitForSteadyState

on the ECS service, I expect it will behave in the same way as your manual process. Either one of these (different defaults depending on whether you are using the raw aws.ecs.Service or the more opinionated awsx.ecs.Service): • https://www.pulumi.com/registry/packages/aws/api-docs/ecs/service/#waitforsteadystate_nodejs • https://www.pulumi.com/registry/packages/awsx/api-docs/ecs/ec2service/#continuebeforesteadystate_nodejs Alternatively, you could

retainOnDelete

the SSM pramater to cause it not to be removed, and then take care of the cleanup maually. But you should be able to accomplish automating the process you describe above.

Hmm thanks, I'll have a look and a test.