https://pulumi.com logo
Join Slack
Powered by
I'm curious if there is a way to lock the pulumi s...
# automation-api
l
I'm curious if there is a way to lock the pulumi state for a stack without performing any operations on it. I want to use that lock as a means of concurrency control in my app, but I have a certain amount of work that has to happen before the stack can be applied. I don't want to do that work unless I have a lock on the state. Is that possible?
t
Interesting question Sam!
l
Is this specifically for Pulumi Cloud? If you are managing your own backend, then you could do this via your backend's normal features.
For Pulumi Cloud with Enterprise, you could use the SDK to change the Team access for the stack. You could flip between permissions that do or do not have write access to the stack.
However, this problem is generally solved by business process, rather than locking state.
For example, our deployment pipeline has a manual gate before 
up
, and our business process is to not pass that gate until the relevant run book has been completed.
l
I'm managing the backend in a google cloud bucket. I'm using the automation API to provide infrastructure as a service so I wouldn't have control over the business flow. I want to have an early guarantee that running a stack will not encounter a state lock conflict while non-pulumi work is being done (timing for that work is on the order of minutes). This way I can fail fast.
l
You could have a (separate!) project for managing that project's state, and your automtion-api program could change the bucket's write permissions for whatever creds your normal deployment uses, without changing the permissions for the state-managing creds.
Wow that's a hard concept to correctly put into words.
That would be fool-proof, in that any attempts to update the stack would fail at the API level. Which means you'd also need extra error-handing code.
An alternative would be to copy what's done in the local file backend, and implement a 2nd-level lock based on your app logic. https://www.pulumi.com/docs/iac/concepts/state-and-backends/#using-a-diy-backend
Your automation-api program could write its own lockfiles into the same bucket. This would lock only your automation-api program, and changes could still be made, but if business process is to use only your program to make changes, then you'd be fine.
But I guess I'm avoiding your original question. The answer might be: Pulumi doesn't provide an API or feature for this, but it does provide docs on where the state files are stored; this means that you can implement equivalent features yourself without too much trouble.
l
These are interesting ideas! Thanks for taking the time to reply.
w
Not sure the exact nature of the "work", but I've used the Pulumi Command package to run various custom things that affect the stack seamlessly as part of the Preview/Up/Destroy process https://www.pulumi.com/registry/packages/command/api-docs/
l
Thanks for the suggestion! For context, my app is a cloud service that deploys applications to edge computing systems. To do this, I'm using the automation API with dynamically generated pulumi programs. The "work" I mentioned is about establishing a tunnel connection to those edge systems and ensuring the APIs the pulumi program relies on are available. My goal is to limit concurrent tunnel connections to those edge systems because of the complexity involved with managing those connections. I was interested in taking advantage of the pulumi state lock as a way to control concurrency, but I ended up using a NATS KV store to handle this instead. It was a relatively simple solution. Although I'm sure there is a way to make it work, I don't think the command package is the best solution for my use case. I'm going to keep that in mind for future needs though.
19 Views
Open in Slack
PreviousNext
Powered by