- 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 initinstead 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
binin .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
.bakfile , 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
pulumiyou 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
mainat 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/):
previewandupWe 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?