https://pulumi.com
Join Slack
This message was deleted.
# general
s
This message was deleted.
g
It depends on the project that I'm doing
If its something very multi-tenant that needs whole chunks of infrastructure isolated for each customer than I prefer to split into packages so I can either create one project per tenant or one stack per tenant if there is only config differences
If is not need such isolations than I prefer to have multiple pulumi jobs and use stack reference
For prototyping and my personal projects I go with monorepo
One of my personal projects has a larger pulumi repo than the ones from work, but since it is just me, meaning there isn't multiple people working on infrastructure at the same time, it is very easy to manage
c
interesting on the prototyping, since i generally spin up a new pulmi app for something like that. i can see long term that using a monorepo for that would make it much easier to not leave resources behind
i was going to use config flags and stack names for the multi-tenancy. so a stack like 
<large-team-stack>-<environment>
or something, and use -c flags to turn on the services they need
or perhaps default to selections of services based on 
large-team-stack
name
i guess doing a refresh may end up taking a long time once the deployment gets very large, and there is the potential for teams to get blocked on each other for releases
especially if someone breaks their service in the release, other releases would be unable to proceed
g
Yeah, multi-tenancy that can be differentiated on configurations works great with stacks. But in some cases you need a different code
c
i may stick iwth Pulumi.yaml’s in each project, and symlink the Pulumi.<stack>.yaml’s up to the monorepo root
g
You can also use meta-repos
I tested it and found it to be a very interesting aproach. Packages ended up as a better fit for the scenario, but you can try meta-repos to see if its better for you
c
i think what i really want is pulumi to search parent dirs for stack configs, like it does for Pulumi.yaml
or i dont use the built in Config class and make one that can handle a centralized config file
l
https://github.com/pulumi/pulumi/issues/3901 will bring some huge benefits to those orchestrating multiple units of infrastructure together, and make it much easier to decompose a monorepo into separate stacks while maintaining the benefits of ease of deployment, teardown, shared config, etc.
l
Oh goody. I'm doing that. There is a little Docker magic involved.. would be good to reduce the level of magic required 🙂
c
yes that issue would be awesome
l
Just wanted to follow up and mention that we merged the first PR for the Automation API Go SDK! https://github.com/pulumi/pulumi/pull/4977 It's in alpha and there will be (mostly additive) breaking changes in the coming weeks. There are complete godocs here that you can check out: https://godoc.org/github.com/pulumi/pulumi/sdk/go/x/auto In addition, there are still a bunch of holes that we'll be plugging over the next few weeks. Here's a list of known issues that we're tracking: https://github.com/pulumi/pulumi/issues?q=is%3Aissue+is%3Aopen+label%3Aarea%2Fautomation-api If you'd like to try it out, you'll need to build pulumi/pulumi as there are CLI changes. We'll cut a CLI release early next week that will make it easier to try all of this out. I'll be updating https://github.com/pulumi/pulumi/issues/3901 with instructions and a call for feedback early next week, but I thought I'd let ya'll know in the mean time in case you're eager to kick the tires. If the feedback on the design is positive, we'll follow up with all of the supported pulumi languages.
Open in Slack
PreviousNext
Powered by

Pulumi Community

No matter how you like to participate in developer communities, Pulumi wants to meet you there. If you want to meet other Pulumi users to share use-cases and best practices, contribute code or documentation, see us at an event, or just tell a story about something cool you did with Pulumi, you are part of our community.

Powered by