colossal-alarm-90650
04/08/2020, 7:27 AMstocky-island-3676
04/08/2020, 7:51 AMname
in the resource argument. The field is sometimes called differently, though. E.g. bucket
for an S3-bucket.
Maybe that helps here.
However, perhaps @broad-dog-22463 could help here 🙂colossal-alarm-90650
04/08/2020, 7:51 AMstocky-island-3676
04/08/2020, 8:00 AMpulumi-aws
?colossal-alarm-90650
04/08/2020, 8:01 AMstocky-island-3676
04/08/2020, 8:07 AM.get()
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 StackReference
. Didn’t try it for myself, yet.
Programmatically only depends on how you name your stacks, AFAIK.colossal-alarm-90650
04/08/2020, 8:08 AMstocky-island-3676
04/08/2020, 8:23 AMcolossal-alarm-90650
04/08/2020, 8:44 AMstocky-island-3676
04/08/2020, 8:54 AMexport const bucketID = bucket.id
& then StackReference
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-90650
04/08/2020, 9:01 AMfaint-table-42725
04/08/2020, 3:47 PM.get
for resources you created in that program..get
is intended to help bridge non-pulumi resources that are already therecolossal-alarm-90650
04/08/2020, 5:25 PMfaint-table-42725
04/08/2020, 5:33 PM.get
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.