This message was deleted.
# generals
sparse-intern-71089
01/27/2019, 12:34 AMThis message was deleted.
w
white-balloon-205
01/29/2019, 6:00 PM
1. What is the support for multiple environments, e.g.: I'd prefer that we have say, 3 accounts instead of 1 account with 3 stacks, is that possible - how do API keys work in this case? What does Pulumi recommend to handle secrets across environments and say, prohibit a "Staging" environment API key from being used to deploy to the "Production" environment?There are several options. You can use any mix of cloud-provider accounts you want, and use either a single Pulumi stack which manages resources in multiple cloud-provider accounts or separate Pulumi stacks for each of the cloud-provider accounts. We provide RBAC as part of the stack management offered by pulumi.com for organiations, so you can restrict which Pulumi user accounts have read/write access to which stacks - which can provide a layer of defense in depth on top of your IAM configuration for you cloud provider. The most common approach here is to have separate Pulumi stacks per environment you are targeting, and set each stack's configuration with the desired secrets. Because it's all just code, you can also do whatever verification you want up front in the deployment to protect against accidentally deploying a stack with incorrect credentials - like comparing the account number of the credentials used for the deployment against a fixed account number that the stack is configured to deploy against, or providing all cloud provider credentials in explicit config so that no ambient credentials are used.
white-balloon-205
01/29/2019, 6:01 PM
2. We use GitLab review apps to deploy many branches to Kubernetes, each as their own independent version of our entire backend/frontend, so we often have many versions of our pre-staging infrastructure running simultaneously. What would Pulumi recommend to handle this case? Are these considered their own "stacks", and would the pricing then be dependent on how manyThe simplest model is that each review app is it's own Pulumi stack. This is actually a really good fit for the stacks model - especially if you automate stack creation/teardown as part of the review app lifecycle. Re: pricing we've definitely heard the feedback on scalability of the pricing model for use cases like this and are working on some changes. @adamant-restaurant-73893 can follow-up to walk through some of what we're thinking there if you are interested. But high-level point is we definitely don't want pricing to be a blocker here - we absolutely want to enable these use cases that involve many small stacks.
g
gifted-island-55702
01/29/2019, 7:20 PMI would also be interested in the planned changes to the stack pricing model 🙂 It would be great to know what we can expect.
o
orange-policeman-59119
01/31/2019, 7:31 PMThanks @white-balloon-205, I would like to hear what @adamant-restaurant-73893 and the company are thinking for evaluating per-stack pricing like this. For what it's worth, we typically have between 4 and 10 review apps going at a time, with 3 engineers on staff. I'd expect that to scale linearly or less as we grow, because eventually we'll have "pods" or "teams" of users which work together on feature branches, as opposed to each engineer typically working on one of a few different features at a time.
orange-policeman-59119
02/04/2019, 9:09 PMHey @white-balloon-205 and @adamant-restaurant-73893, any update on this?
orange-policeman-59119
02/06/2019, 11:53 PMHey @white-balloon-205, can you poke @adamant-restaurant-73893 on this? 🙂
w
white-balloon-205
02/06/2019, 11:59 PM
Will do 🙂.
a
adamant-restaurant-73893
02/07/2019, 12:36 AMSuccessfully poked - and sorry for the tardy response!
adamant-restaurant-73893
02/07/2019, 12:37 AMEssentially, we are looking at a 'per user' option for pricing. We have work to do on this both from a packaging perspective, and product/engineering perspective. However, we recognize this might be preferable for certain teams. So... nothing to announce, but if you are serious about purchasing on that basis, then DM me and we can talk in detail on that.