4 ms·

No built-in remote state backend storage (s3, gcs, etc) locking except their proprietary hosting. Obviously they need to make money, but this makes driving migr

No built-in remote state backend storage (s3, gcs, etc) locking except their proprietary hosting. Obviously they need to make money, but this makes driving migration from terraform to pulumi a lot more difficult.

flurie 7y ago
This was true when it was first released, but they now allow you to bring your own backend store. https://www.pulumi.com/docs/intro/concepts/state/ https://www.pulumi.com/docs/intro/concepts/state/
- terrorbilly 7y ago
  It's specifically the state-locking feature that's missing from 3rd party backends.
- edaemon 7y ago
  That page lists this as a feature of their service, implying it isn't available in other backend stores: Concurrent state locking to prevent corrupting your infrastructure state in a team environment
kraig 7y ago
I've got a PR opened to implement this but due to S3 CAP limitations, it hasn't been merged. The current state is that it could be merged for non-S3 backends and a DynamoDB type lock could be added for S3 backends. I don't have much interest to keep pushing it forward (its been nearly a year of "ill get back to you next week") although their new VP has been more responsive. Alternately I was considering just implementing the server API to do state storage & locking, but we have implemented some workarounds that are good enough for now.
- terrorbilly 7y ago
  I just want to say thanks for your initiative on opening https://github.com/pulumi/pulumi/pull/2697 https://github.com/pulumi/pulumi/pull/2697. (I've seen you active on a few other issues and in the Slack channel too) I think it's really unfortunate (whatever the reason) that the team was this slow to provide meaningful feedback on the PR.