https://pulumi.com logo
#general
Title
# general
g

gorgeous-minister-41131

02/15/2024, 1:11 AM
Does anyone here mix-and-match different resource provider resources? e.g. k8s stuff intermingled with AWS stuff? If yes/no, why, why not and what kind of issues does it cause? The first thought I had is with k8s, makes it impossible to separate concerns with automation and the executor that runs the pulumi code (operator, automation, cli etc) will need a lot of permission all at once to do what it needs to do...
l

little-cartoon-10569

02/15/2024, 1:24 AM
Yes, lots of us do, and it's not a problem. Resources created with one provider never use other providers. You will undoubtedly need ids and other strings, but not entire resources. So it's never a problem (afaik).
g

gorgeous-minister-41131

02/15/2024, 1:50 AM
Oh, I should have been more clear sorry: I mean't in the same project.
We use ArgoCD and like to GitOps, which means bake our k8s manifests and Sealed secrets. When rendering YAML with Pulumi that gets weird. However, I think if we bought into the Pulumi Kubernetes Operator ecosystem, then mixing and matching these resource providers would be fine.
l

little-cartoon-10569

02/15/2024, 1:52 AM
I meant in the same project, too.
It works fine.
What is "gets weird"? Can you show some code that renders YAML with Pulumi? Maybe I can help.
s

salmon-account-74572

02/16/2024, 5:48 PM
Generally, providers aren't one of the deciding factors when trying to figure out how to organize resources within and among your Pulumi projects. This article provides some guidance on how to think about this: https://www.pulumi.com/blog/iac-recommended-practices-structuring-pulumi-projects/ Based on what you've shared, I might separate AWS and Kubernetes resources into separate projects solely because of resource lifecycle---generally you're more likely to up/refresh/destroy K8s resources more frequently than the underlying AWS resources.
g

gorgeous-minister-41131

02/21/2024, 8:56 PM
Thank you for the feedback all. I think what I've done some thinking about: I do like the notion that resources that are more likely to be updated being separated logically into projects from less likely and possibly using inputs via config and relying on exported outputs being a way to tie things together using the Automation API.