colossal-alarm-9065004/08/2020, 7:27 AM
stocky-island-367604/08/2020, 7:51 AM
in the resource argument. The field is sometimes called differently, though. E.g.
for an S3-bucket. Maybe that helps here. However, perhaps @broad-dog-22463 could help here 🙂
colossal-alarm-9065004/08/2020, 7:51 AM
stocky-island-367604/08/2020, 8:00 AM
colossal-alarm-9065004/08/2020, 8:01 AM
stocky-island-367604/08/2020, 8:07 AM
functions don’t offer you to get by tag, then I suppose it’s not possible, yet. With accessing stacks you mean accessing the `output`s of a stack? Sure, that’s possible with the
. Didn’t try it for myself, yet. Programmatically only depends on how you name your stacks, AFAIK.
colossal-alarm-9065004/08/2020, 8:08 AM
stocky-island-367604/08/2020, 8:23 AM
colossal-alarm-9065004/08/2020, 8:44 AM
stocky-island-367604/08/2020, 8:54 AM
export const bucketID = bucket.id
that in the other project. “good reason”: See the raw stack like a database. It shouldn’t be touched nor accessed directly. Only from the program knowing about its internal structure. I.e. Pulumi itself.
colossal-alarm-9065004/08/2020, 9:01 AM
faint-table-4272504/08/2020, 3:47 PM
for resources you created in that program.
is intended to help bridge non-pulumi resources that are already there
colossal-alarm-9065004/08/2020, 5:25 PM
faint-table-4272504/08/2020, 5:33 PM
you’re losing an important aspect of the abstraction — the “API” between you and that team is the identifier of the resource. This is very brittle in comparison to referencing the actual ‘thing’ you care about (e.g. an ElasticSearch cluster or whatever it is). If that underlying resource (under the control of some other team) changes for whatever reason, your stack updates will pick that up vs. relying on the name as the API.