- did brew install pulumi, installed 1.0.0 , running it keeps nagging about brew upgrade to 1.0.1
- I wonder if there is a phone-home option, then it needs an optional opt-out
- I'd expect
pulumi init
instead of new - pulumi needs documentation on the bootstrap for the state bucket (correct permissions)
- pulumi login defaults to the saas platform, and says alternative logins available. not too clear , a select local would be nice
- also the path where is stores the files should be asked for during installation
- pulumi new --secrets-provider=passphrase (default I assume) has no way to initialize the secret from the CLI (like reading it from stdin or file)
- why is
bin
in .gitignore (because typescript compiles in ./bin) - should have README with a good documentation template, like params to set
- removing a stack doesn't really remove it , it makes it a
.bak
file , and they are still under backups and checkpoints - why are the templates under
.pulumi
? will they change on updates? can I use change them myself? - I didn't get plan = preview and apply = up is both ; still missing a binary compiled plan for later execution
- It seem to be missing a concurrency/lock mechanism to avoid run/change conflicts (compiled plans helped there in TF)
- properly name spacing stacks makes sense to avoid conflicts with same state
- pulumi stack requires aws access, no local state aparently of a stack
- wonder how you can change the secret of the passphrase provider later
- stackname use the name entered of the project during pulumi new
Pulumi.yaml
- plugins are downloaded on first use, can you run this step before to avoid log pollution?
- when I run an empty stack , why does it want to run/create something?
- why create stack signed url perma-links? security I don't like it
- why is it creating stack yaml files in my project directory (maybe I once did a login to this file:// dir, but then removed all .pulimi)
- I miss the good structure of resource documentation like terraform has
- suprised vpc is under aws.ec2
- vs code does code completion but doesn't have a good struct of a new resource snippet
- wonder how I can do a data resource like in terraform
- from a coding perspective , I miss a sort of run or build action ; it's strange that just by using a constructor of a class things get executed
- pulumi login seems to be global, for files you can probably specify other pathsm but there is no env settings to change this easily
- pulumi stack names are global, not per project/customer, maybe .pulumirc to override?
- a stack name may only contain alphanumeric, hyphens, underscores, or periods, warning should be before entering a name
- no slashes means no directory name spacing in s3
- wonder what .pulumi/workspaces are
- why do I need a binary install? why not just have the bin installed with npm install?
- how will I be able to run multi version pulumi
- how do you debug/interactively
- stackreference is like remote state in terraform
- can you have multiple entrypoint into a project (only up subpart of a stack)
- better examples on complex structure (like lib/)
- tests are currently not real tests but only run after runtime provisioning
- renaming a stack was kinda clunky (need to recheck)
- refactoring custom resources will have no impact on the dependent resources
- autonaming (appending random string) s3 bucket - default should be exact, not the other way around
- pulumi needs a proper hashtag that is not poluted
- remote state , how about readonly access?
Mappings of projects to folder to track things like currently active stack in a folder.
You mean the plugin binary I assume? We considered including in the NPM pacakge, but since it needs to be tied to the native platform - we would need lots of different architectures, and instead we just download it in a post-install hook. This should result in the same experience 99% of the time, but without paying the cost of unneeded large binaries in NPM.
You can use whatever versions of packages you want per-project. You can install whatever versions of
pulumi
you need and invoke the ones you want when you need them (or isolate with Docker or VMs).Currently just
console.log
, but proper debugging will be possible and is tracked in pulumi/pulumi#1372.Yep - and we also support remote state references to Terraform as well.
Yes - or more accurately - you can have two projects, each with it's own entrypoint into the same codebase. See
main
at https://www.pulumi.com/docs/intro/concepts/project/.What were you looking for exactly here?
We have a few different options for test (described in https://www.pulumi.com/blog/testing-your-infrastructure-as-code-with-pulumi/ and https://www.pulumi.com/blog/unit-testing-infrastructure-in-nodejs-and-mocha/):
preview
andup
We do now (as of fairly recently) support https://www.pulumi.com/docs/reference/cli/pulumi_stack_rename/ - did that not work as you expected?
Not sure precisely what you have in mind here - but Pulumi in general should support refactoring components in many different ways with no unexpected impact on resources that are unaffected - in part by using https://www.pulumi.com/docs/intro/concepts/programming-model/#aliases.
This is something we continue to think about changing - it would be a big change, and there are important correctnessflexibility reasons for this. We've added details on the reasoning at https://www.pulumi.com/docs/intro/concepts/programming-model/#autonaming and https://www.pulumi.com/docs/troubleshooting/faq/#why-do-resource-names-have-random-hex-character-suffixes. But it's something we continue to weigh.
You mean on Twitter? We've considered encouraging
#pulumiup
- thoughts?For the S3 backend, this can be enabled via IAM permissions on the bucket. Was there something more you are looking for here?