This message was deleted.
# general
s
This message was deleted.
b
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
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
You can export things you need from your stack and then use
pulumi stack output
to reference them from outside.
p
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
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
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
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
Thanks for help! I'll give it a try.
s
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
@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!