# aws


03/15/2024, 4:28 PM
Hello, I have several AWS ECS Fargate services which are independent of each. I expected that Pulumi will carry out the upgrades to these services in parallel during deployment since they don't depend on each other. Yet, I see the updates happening one by one and Pulumi waiting on each one to finish before proceeding to the next ECS service. I am using AWSX 1.0
with TypeScript and I am also using the
continueBeforeSteadyState = false
. The flag seems to be causing this because when I remove it, I see Pulumi issuing all the updates in parallel and not waiting for any of them as expected. It seems that you should be able to wait on several services updating in parallel with the flag set. Is this a limitation, a feature request or perhaps I am missing something?


03/15/2024, 9:01 PM
Hi @little-market-63455. This is not expected - you should see parallelism between resources where there are not dependencies between them. Does setting the
--parallel 0
flag to have unbounded parallelsim help for you? If you could capture a trace with and share it with me in DM, we could potentially look into what is limiting the parallelism in the update for your use case.


03/16/2024, 12:20 AM
I will check the trace first time I get a chance. Thank you
I have sent a trace file from a run I did locally with
pulumi up -f --tracing=file:./up.trace
Thanks for looking into this
--parallel 0
makes no difference. everything seems to be updated in parallel until it reaches the ECS services and then it seems to be going one by one


03/28/2024, 4:06 PM
Hi @white-balloon-205 I'm not sure if you continued this in DM, but is there a resolution for this? I have the same issue (ECS services do not update in parallel), even on services in different clusters, for which I don't think there are any inter-dependencies. Tried
--parallel 0
and no luck either. Is there a general way to hint or force Pulumi to do parallel updates when I 'know' there are no deps between two resources? That might be nice as an escape hatch
I put a minimal reproduction of this issue here: (although I'm not 100% sure it's an AWSX issue, that's just the highest level I repro'd it at)


04/04/2024, 6:41 PM
We ended up implementing a custom component resource which seems to be a fix for what we want with minimal hackery