https://pulumi.com logo
Join Slack
Powered by
This message was deleted.
# getting-started
s
This message was deleted.
b
I don't think it's necessarily wise to mix resources between projects/stacks.. or at least if you do, you should never modify the parts under control by another stack. For instance it's perfectly fine to have one stack set up infrastructure like networking, storage, kubernetes, vms, databases, etc - and then another stack manage the contents of kubernetes, access to the database etc. but modifying the database configuration from the second stack isn't really the right approach
Think of it more like distinct areas of responsibility.. if you want to modify the SQS resource based on the lambda project - perhaps the lambda project should also be responsible for the SQS
v
Yes, since the lambdas are based on SQS events, i think it's impossible for the lambdas project to not modify an already defined SQS (on another project). Thanks for the reply!
b
One thing you can consider though.. you can output enough information about the SQS from your first project that your second project can "pick up" where it left off
that way you can use stackReference to connect to the output - but beware that the first stack will be unaware of any changes made to SQS, so if your initial SQS is so declarative that it it prescribes absolute contents, that might be an issue.
so if the lambdas simply consume and produce to the SQS queues, the reference from the previous stack should be sufficient. otherwise there should be a lambda that is the "owner" of the SQS (i.e. primary producer) that dictates its settings and existence, then others can consume based on that.
v
Not easily infered by the API, but i think this helps connecting to existent infrastructure without having to deal with ownership: https://www.pulumi.com/blog/easy-serverless-apps-and-infrastructure-real-events-real-code/#connect-to-an-existing-resource
3 Views
Open in Slack
PreviousNext
Powered by