A question on stack organization: I have a few mic...
# getting-started
c
A question on stack organization: I have a few micro-stacks for one cloud provider and I want to set up an analogous setup for another cloud provider. The actual resources will obviously be different but the logical purpose of the stacks will be the same (e.g., share many configuration parameters, provision a database, create a managed kubernetes cluster) and for certain stacks which just provision a bucket or two, there will basically be a one to one correspondence between resources. I assume the choices are (1) parallel but different pulumi projects, or (2) same project but different stacks that dispatch on a configuration parameter. I'm wondering if anyone has any experience with either of these options or know of other approaches?
For context, in other scenarios we have used a common language level library to share common functionality between stacks or used stack references to loosely couple things
We use pulumi deployments and other pulumi cloud features, so I am wondering if there is going to be a problem if a project uses two different cloud providers.
l
You cannot use different stacks in the same project for this purpose, except by wrapping all of the resources in a conditional that selects one target or the other, at which point, you have to acknowledge that there is no relationship between the different stacks. These are different projects. You can use the same program code and a factory-type pattern to re-use all your non-provider code, and that would work fine in 90% of the code. You'd probably still need a little conditional logic, since it's highly likely that different clouds would use resources in fundamentally incompatible ways (e.g. a "firewall" resource in one cloud might require 10 resources, and it might require 30 resources in another cloud, just because of the underlying technology differences). Pulumi used to publish a cloud-"(sort-of-)"agnostic provider that wrapped "compute", "storage", "network" etc, and then translated it to Azure/AWS/GCP based on the provider configuration. I never used it, I can't find it in the registry now and I can't even remember what it was called. I guess it's been officially abandoned? Wrapping "all the things" in a single library is doable, but it's not very maintainable...
Ooo found the provider by trawling GitHub. It is officially archived: https://github.com/pulumi/pulumi-cloud
The rationale for not using "resource model abstractions" is summed up in the archive-this-repo ticket: https://github.com/pulumi/pulumi-cloud/issues/844
c
Many thanks! This is what I was thinking was the path but it is good to get confirmation.