Scott Lowe

When I first saw this post, I was going to reply that all was quiet for me. That changed pretty quickly! Now getting tons of “Storm event push” notifications.

Had the same thing happen to me this morning! 🤣

To be clear, I am speaking extensively with the installer, and they are being very helpful.

Thanks for these links! I’ll review them.

Ha! Good advice. Lucky for me I did that already. 👍🏻

Apologies for the delayed response!

If I’m understanding your question correctly, you can use the pulumi.getStack() to get the stack name and then use that programmatically in your Pulumi program.

(Disclaimer: I'm a Pulumi employee, but I was a user before I joined the company.)

I find myself needing to switch between my personal account (free forever individual user tier) and my corporate account. I accomplish this by setting the PULUMI_HOME environment variable to a filesystem location that contains credentials for my personal account, and then using direnv to change that on a per-directory basis to a filesystem location that contains credentials for my corporate account. It's a bit of a hack, but it works well.

I was recently introduced to sops (https://github.com/getsops/sops) which, if I'm not mistaken, offers some integration into the external-secrets project for Kubernetes. That would allow you to store encrypted secrets in a Git repository and then provide the decrypted values to your pipelines.

There's also Pulumi ESC, which can be used independently of Pulumi's infrastructure as code offering, that allows you to store secrets and configuration values and retrieve them with a simple CLI utility. Just be aware that ESC is not yet GA, so while it's fully functional no decisions have been made around pricing and packaging.

I don't know that I'd say learning Python is mandatory, but it's typically better suited to lightweight scripting and automation tasks than something like Java. I think it's probably worth your time and attention.

There's a wealth of practical knowledge and examples in this thread. This really is a matter of "using the right tool for the job." Honestly, the people in this thread have been so thorough that it would be difficult to find a use case that folks haven't yet covered. :-)

To echo/support what others have said, this is because Pulumi does not (by default) run a refresh when you run pulumi up. There are ways around that, naturally. You can add the -r flag, as in pulumi up -r. This tells Pulumi to run the refresh before the update, and in this particular case it should address your concern.

It's also possible to instruct Pulumi to refresh automatically as part of the project configuration in Pulumi.yaml. The benefit of this approach is that any user using this project would be affected and would not need to remember to use the -r flag. Add this to your Pulumi.yaml (note that options is a top-level keyword, at the same level as name or runtime):

options:
  refresh: always

I hope this helps!

I'll have to echo the thoughts of others and recommend Ansible. For existing workloads, it's the tool I'd reach for first.

For new workloads, you could leverage cloud-init and/or build your own VM image, but this doesn't sound like what you're needing in this moment.

OK, so the concerns regarding state file concurrency are with a DIY backend hosted on S3. Thank you for that---this gives me enough information to talk to our engineering team about your concern.

You're correct, the examples in the API docs are autogenerated based on the types. We have a massive effort underway to improve the quality of our API docs, so I'm hopeful that this will result in a meaningful improvement in the volume and quality of the examples. I'll see if I can find an issue about import information with Golang, and create one if one doesn't already exist.

Honest feedback is useful, regardless of who it comes from, so thanks for taking the time to respond. It sounds like you're using a DIY backend, right? Which platform/service are you using for your backend? WRT to the docs, "they are crap" is a bit vague. :-) Are there any specific changes you'd like to see in the docs?

Using pulumi preview --diff (I believe that's the right command, working from memory) to show a rich diff of the changes might provide additional details on where/why/what it wants to delete or change things. I'll look up your comment on our Slack instance and see if I can help further.

There are forms of complexity inherent in every product, but it does sound like we could do a better job of explaining the differences/pros and cons of each approach and how they relate to one another. I'll file an issue in our docs repository to that effect.

I would like to point out that Pulumi does not rely on ANY BSL-licensed code from HashiCorp, nor is it a wrapper around Terraform. That's a common misconception.

Thanks for your feedback!