:smile:
# general
e
😄
w
We don't currently have a way to "get-or-create", though it's somethine we could consider adding. We generally want to be able to think about a Pulumi program owning the definition of a given resource. Without this, it is hard to reliably know that the desried state you are specifying will really be applied. A solution to your general problem might be to introduce a third shared stack which creates the Streams and that must always be stood up first, and then the other two stacks can reference it's outputs and use those.
e
mhhh, ok. is there a way to check if a resource already exists directly from pulumi and if it's managed by that specific pulumi app?
the 'ugly' solution i thought about was checking if the state file of pulumi had the kinesis stream defined. if it had, i can do the new kinesis.aws.... no matter what, as it will potentially just be in the same state. if i have a state file and it does not have that kinesis, i check to see if the kinesis stream exists with the getStream, and if it does, i just skip the new kinesis.aws.
w
There are ways you could do this (like load up the AWS JS SDK and query), but this sounds like it's trying to go against the grain of Pulumi a fair bit, so I'd be interested to better understand the scenario to see if there's a better way of solving for this with Pulumi.
Can you tell me why you want both of these programs to define the desired state of the Kinesis steam?
e
sure
so i have different environments
dev, staging, prod
and they get input data from a kinesis stream that i may potentially want to share between them
so the pulumi app to deploy those is pretty much the same but takes into account the env, and modifies the resources names by appending env
but i may need the different environments to have the same input data, so i'd like to share that kinesis input stream
if that makes sense
w
Yep - that makes sense so far. But then can't the Kinesis Stream to use just be a config input to each stack? And have it actually be created/owned by some other stack that is stood up independently (and has a differen lifetime and relationship to each of these other stacks)?
e
it's an option, but we were trying to keep it all in a single pulumi app for each env
but i see what you mean