This message was deleted.
# generals
sparse-intern-71089
02/15/2024, 1:11 AMThis message was deleted.
l
little-cartoon-10569
02/15/2024, 1:24 AMYes, 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 AMOh, I should have been more clear sorry: I mean't in the same project.
gorgeous-minister-41131
02/15/2024, 1:51 AMWe 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 AMI meant in the same project, too.
little-cartoon-10569
02/15/2024, 1:53 AMIt works fine.
little-cartoon-10569
02/15/2024, 1:54 AMWhat 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 PMGenerally, 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.
👍 1
g
gorgeous-minister-41131
02/21/2024, 8:56 PMThank 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.