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?

Great feedback! Replying on the first few - we'll get back on the rest shortly.

did brew install pulumi, installed 1.0.0 , running it keeps nagging about brew upgrade to 1.0.1

This is now fixed, and ensuring this can never happen again is tracked in pulumi/pulumi#3230.

I wonder if there is a phone-home option, then it needs an optional opt-out

There is the option to use the local backend which removes almost all elements of "phone-home" other than the latest-version check. The latest-version check can be disabled by setting PULUMI_SKIP_UPDATE_CHECK which is documented at https://www.pulumi.com/docs/get-started/install/.

I'd expect pulumi init instead of new

There is a pulumi stack init which creates just a new stack - without templating out a project. Fair feedback though. We do suggest pulumi new for users who type pulumi init so hopefully that helps with deiscoverability.

pulumi needs documentation on the bootstrap for the state bucket (correct permissions)

Yep! https://github.com/pulumi/docs/issues/1666.

pulumi login defaults to the saas platform, and says alternative logins available. not too clear , a select local would be nice

Yep! pulumi/pulumi#3152.

also the path where is stores the files should be asked for during installation

You mean the path within a bucket? We do of course let you pick a folder on disk or a bucket - but not sure that we support a path into a bucket. This is definitely a reasonable suggestion for a future addition.

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)

I believe it's actually the opposite - it can only be provided via the prompt on stdin - and cannot be provided in a command line argument. Curious what specific approach you expected/wanted that wasn't supported?

why is bin in .gitignore (because typescript compiles in ./bin)

This is actually an artifact of an old approach Pulumi used where TypeScript compilation was done separately (into a bin folder). Now it is done on-demand within Node.js into a temp folder. So this is likely unnecessary for folks who use the default, but is still useful for folks who choose to opt out of this per https://www.pulumi.com/docs/intro/languages/javascript/#disabling-built-in-typescript-support.

should have README with a good documentation template, like params to set

Do you mean in the templates themselves? That's a good idea - though we've generally wanted to keep these as light as possible (there are already more files than we'd like - just due to the needs of NPM, TypeScript, etc.). Our expectation is that users will quickly change the contents of these templates - so any README about the details of the specific template would quickly be unhelpful. Was there anything in particular you had hoped to see there that wasn't already clear from the source code?

removing a stack doesn't really remove it , it makes it a .bak file , and they are still under backups and checkpoints

That's right - pulumi itself no longer tracks it, but files associated with it are not proactively removed. I would note that we have frequently had users remove a stack and then regret it and want to recover. I suspect we would want to have an opt-in flag to force remove all of this with another big warning on it.

why are the templates under .pulumi ? will they change on updates? can I use change them myself?

That is just a cache to avoid needing to download every time in case there are not changes. I suspect you cannot reliably make edits there (it will be overwritten if there are updates to templates in the source location. In general - the contents of ~/.pulumi are intended to be an implementation detail - not something users will ever need to or should hand modify.

I didn't get plan = preview and apply = up is both ; still missing a binary compiled plan for later execution

Pulumi doesn't currently have a serialized plan artifact. Providing a stricter interface between preview and update is tracked in pulumi/pulumi#2318.

It seem to be missing a concurrency/lock mechanism to avoid run/change conflicts (compiled plans helped there in TF)

The Pulumi service backend does support this, but the filestate (local and remote) backends do not. Support for them is being worked on in pulumi/pulumi#2697, though there some fundamental correctness limitations for some of these without additional infrastructure.

properly name spacing stacks makes sense to avoid conflicts with same state

If I understand this - I think it may be related to pulumi/pulumi#2522 - which is another limitation of the current filestate backend.

pulumi stack requires aws access, no local state aparently of a stack

I don't quite follow this one. The only thing that requires AWS access is managing a resource in AWS, or if you choose to store your state files in S3.

wonder how you can change the secret of the passphrase provider later

Currently you cannot - you need to create a new stack (and export/import state file). Enabling changing secrets provider (including changing passphrase for using the passphrase provider) is part of pulumi/pulumi#481.

stackname use the name entered of the project during pulumi new Pulumi.yaml

Yes - stack names in general are org/project/stack. For the filestate backend, the org part of is included.

plugins are downloaded on first use, can you run this step before to avoid log pollution?

Plugins should be downloaded during first npm install that uses the required version. This is about as early as it is possible to know what version to download. Was there something else in particular you had in mind?

when I run an empty stack , why does it want to run/create something?

There is an implicit "Stack" resource which represents the parent of all resources managed by the stack. This can be a little surprising especially in the case where there are no resources, but does generally allow the model to be more uniform - for example, stack exports are just properties of the Stack resource.

why create stack signed url perma-links? security I don't like it

This is for the S3 backend I assume? Fair feedback - what would you suggest here - just URL to the console that requires login?

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)

The Pulumi.<stackname>.yaml file is where configuration for the particular stack is stored. This is a file that you will typically version-control for each long-lived stack - for example Pulumi.production.yaml inside the website project would be the production stack of your website, and would store the configuration associated with that. It is stored here to improve the ability to source control it effectively.

I miss the good structure of resource documentation like terraform has

I expect in particular you mean have a single, clean and simple page per resource? Definitely agreed - and pulumi/docs#1421 is tracking improving layout of these docs.

suprised vpc is under aws.ec2

Agreed - though that is where AWS puts it in their APIs and and in CloudFormation - for example: https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-ec2-vpc.html. We felt it important to be consistent with AWS here.

vs code does code completion but doesn't have a good struct of a new resource snippet

What did you have in mind here? Do you mean autofilling required properties with a snippet?

wonder how I can do a data resource like in terraform

aws.ec2.getSubnetIds is equivalent to data "aws_subnet_ids"

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

What would you want this to look like? Note that nothing really gets executed. During a preview for example, just a data structure gets built. During an update, the same happens, but Pulumi then works to reconcile that data structure with the current state and schedules work. But the program doesn't specify the work to do - just the desired state to construct.

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?