Pulimi feedback

feedback.md

Installation

• 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

Using

• 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

Organization

• 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

Random thoughts

• 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?

pulumi login seems to be global, for files you can probably specify other pathsm but there is no env settings to change this easily

Yes - currently the "backend" you are logged into is global. A lot of the issues related to this are tracked in pulumi/pulumi#2814, and it is likely we will want to allow the active backend to be tied to a specific project instead of global.

pulumi stack names are global, not per project/customer, maybe .pulumirc to override?

This again is specific to the filestate backend, and is tracked in pulumi/pulumi#2522.

a stack name may only contain alphanumeric, hyphens, underscores, or periods, warning should be before entering a name

Good callout - this may also be specific to the S3 backend. What error did you get, and at what point?

no slashes means no directory name spacing in s3

Yes. I think that's intentional at the level of individual Pulumi stacks - but we should allow directing the state file to various different paths within the backend. This is again related to pulumi/pulumi#2814.

wonder what .pulumi/workspaces are

Mappings of projects to folder to track things like currently active stack in a folder.

why do I need a binary install? why not just have the bin installed with npm install?

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.

how will I be able to run multi version pulumi

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).

how do you debug/interactively

Currently just console.log, but proper debugging will be possible and is tracked in pulumi/pulumi#1372.

stackreference is like remote state in terraform

Yep - and we also support remote state references to Terraform as well.

can you have multiple entrypoint into a project (only up subpart of a stack)

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/.

better examples on complex structure (like lib/)

What were you looking for exactly here?

tests are currently not real tests but only run after runtime provisioning

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/):

1. An integration testing framework which stands up infrastructure, runs arbitrary validation against it, and tears it down
2. A test mode that allows writing unit tests in Mocha or other JS test frameworks against the resource model
3. Ability to incorporate tests into the deployment process to verify how resources are being constructed during preview and up

renaming a stack was kinda clunky (need to recheck)

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?

refactoring custom resources will have no impact on the dependent resources

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.

autonaming (appending random string) s3 bucket - default should be exact, not the other way around

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.

pulumi needs a proper hashtag that is not poluted

You mean on Twitter? We've considered encouraging #pulumiup - thoughts?

remote state , how about readonly access?

For the S3 backend, this can be enabled via IAM permissions on the bucket. Was there something more you are looking for here?