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

proud-art-41399

05/11/2021, 6:32 AM
Hi, let's say I have a part of my infrastructure provisioned by Pulumi while the rest is not. Some services from the non-provisioned part need to access resources that are Pulumi-managed (e.g. they need to call Lambdas). What's the best / most aligned way how to reference those provisioned resources? What comes to my mind: • Name those Pulumi-provisioned resources explicitly (i.e. don't use auto-naming). • Use auto-naming but then store the names somewhere (e.g. SSM Parameter Store, but then I'd need to name the parameters' paths explicitly). • Maybe just stick to knowing which project/stack the resources are managed by and somehow ask for the outputs (but I don't know how to achieve this at the moment). Thanks for hints!
b

bored-oyster-3147

05/11/2021, 12:44 PM
Have you considered looking into service discovery?
However if that is overkill - I would go with your second route and have explicitly named parameters in SSM
p

proud-art-41399

05/11/2021, 1:16 PM
Yeah I think in this case service discovery would be an overkill. And maybe wouldn't solve the problem in the first place too – it's not just services that need to be known, but also other kind of resources. But maybe that's just my misunderstanding of what service discovery encompasses (I have no experience with it). Anyway, thanks for advice, I also find the second approach most viable.
s

some-advantage-5649

05/11/2021, 6:03 PM
You can export things you need from your stack and then use
pulumi stack output
to reference them from outside.
p

proud-art-41399

05/11/2021, 6:43 PM
IMHO this is applicable only when both components are managed by Pulumi. Then I can use stack references. But in my case, the second component/application is not (yet) managed by Pulumi and thus I would need to refer to the first components' stack outputs programatically. I thought an Automation API would be of help but wasn't successful. But I might be plain wrong and there is a way.
b

bored-oyster-3147

05/11/2021, 6:48 PM
Automation API should be doable. You should be able to get the stack and then programmatically retrieve it's outputs. Did you have any specific issues there that I could help with?
p

proud-art-41399

05/11/2021, 7:21 PM
Well, I wasn't able to bootstrap it at all. I'm using a S3 backend and couldn't find a way to "login" to the backend so that I could then call reference the already existing stack.
b

bored-oyster-3147

05/11/2021, 7:32 PM
Gotcha, yea you need to either use an environment variable or you need to specify the backend in the project settings file. Since Automation API doesn't have
pulumi login
the login is stateful. There is a
backend
property in the project settings that you can set, and you can do that programmatically when you point at your existing project via Automation API
p

proud-art-41399

05/11/2021, 7:36 PM
Thanks for help! I'll give it a try.
s

some-advantage-5649

05/12/2021, 5:04 AM
IMHO Automation API is unnecessary dependency for you unmanaged components. It should be as easy as to get endpoints via CLI (as I mentioned) in build/deploy time and set it as EVNs or config values.
p

proud-art-41399

05/12/2021, 5:40 AM
@some-advantage-5649 you are right, I can get the first stack's outputs and inject it into the environment in a CI step of the second app. For some reason this approach didn't strike my mind but seems the most elegant option after all. Thanks!
3 Views