Hi team, what does 5 concurrent updates mean in th...
# general
m
Hi team, what does 5 concurrent updates mean in the context of pulumi team plan? Like is it that we can only deploy 5 instances at a time, where 1 instance is deployed per stack. Or something else? we are using automation API so wanted to understand what does the term mean because we are seeing some unpredictible behaviour when deploying multiple things together?
i
Each project stack can only have 1 concurrent update, if you try to
pulumi up
on a project that is already in an update phase it will fail 5 concurrent updates mean 5 stacks can be updated concurrently under your organization This only applies if you're using the Pulumi Cloud as a state backend. If you implement your own state backend you won't have the quota, but you'll miss out on the Pulumi Cloud UI which I find very helpful
m
Is create same as update? Because our use case is creating many stacks at same time? so we didn’t face such limitations so curious what does update mean? Also does the same rules apply to destroy as well? Because we do create -> destroy loops with a lot of stacks at same time
i
Yes, every time you manipulate your stack (create, update, delete) it’s known as an “update” Login to app.pulumi.com and then find one of your stacks, then open the Updates tab
m
I created 10 parallel deployments using automation API and it takes almost same time
Copy code
started stack creation for stack-9 at 17 Dec 23 14:44 IST
started stack creation for stack-4 at 17 Dec 23 14:44 IST
started stack creation for stack-1 at 17 Dec 23 14:44 IST
started stack creation for stack-2 at 17 Dec 23 14:44 IST
started stack creation for stack-0 at 17 Dec 23 14:44 IST
started stack creation for stack-3 at 17 Dec 23 14:44 IST
started stack creation for stack-7 at 17 Dec 23 14:44 IST
started stack creation for stack-8 at 17 Dec 23 14:44 IST
started stack creation for stack-5 at 17 Dec 23 14:44 IST
started stack creation for stack-6 at 17 Dec 23 14:44 IST

finished stack creation for stack-1 at 17 Dec 23 14:45 IST (took 49.841123291s)
finished stack creation for stack-7 at 17 Dec 23 14:45 IST (took 50.839095834s)
finished stack creation for stack-9 at 17 Dec 23 14:45 IST (took 50.907013084s)
finished stack creation for stack-0 at 17 Dec 23 14:45 IST (took 50.942905666s)
finished stack creation for stack-3 at 17 Dec 23 14:45 IST (took 51.186405s)
finished stack creation for stack-4 at 17 Dec 23 14:45 IST (took 51.225100125s)
finished stack creation for stack-2 at 17 Dec 23 14:45 IST (took 52.1078165s)
finished stack creation for stack-6 at 17 Dec 23 14:45 IST (took 53.170794875s)
finished stack creation for stack-8 at 17 Dec 23 14:45 IST (took 53.795009458s)
finished stack creation for stack-5 at 17 Dec 23 14:45 IST (took 53.909173833s)
What does this mean? Is the limit imposed some other way or is there something else i’m overlooking?
Created a demo program for verifying this.
same behaviour with trying to create 20 instances in parallel
i
My guess is that it is applied to tasks where you execute “pulumi up”
m
Isn’t it same as calling stack.Up in automation API
Copy code
result, err := s.Up(ctx)
	if err != nil {
		return errors.Wrap(err, "could not create stack")
	}
which internally calls the pulumi up command
i
True, and it looks like you’re not hitting any type of limit