https://pulumi.com logo
Join Slack
Powered by
This message was deleted.
# general
s
This message was deleted.
s
Hi @colossal-alarm-90650. You still have the same or similar problem as last week? When you want to avoid the suffix in the name, then you could set the 
name
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 🙂
c
Oh I figured that one out. No, I am trying to eat the cake AND keep it.
If I can find the name used in the stack, I’m getting around the problem of the obfuscated name, and I could make a get function that actually would work.
Frankly… I don’t quite understand why this isn’t an option in the get functions as is… a “get the currently registered object with this base name”-function?
s
You already created an issue in 
pulumi-aws
?
c
Nope. If it’s not a bug, it’s not an issue. If there is a workable way to do this I want to find that out. I suppose you’re saying it isn’t possible? Stacks cannot be accessed programmatically?
s
If the 
.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.
c
Well… I can get the name of the current stack with “getStack”. What I need then is the actual content as I would get with the cli “pulumi stack export” which I then could loop through looking for the resource in question….
s
Oh no, programmatically “sniffing” through the raw stack isn’t supported. And that’s intended for good reason. So: Why not using `StackReference`s? See inter-stack dependencies.
c
Hm. At first look that says nothing about how to get a reference to a name-obfuscated object… it’s about “outputs” of which none seems to be relevant (or defined, maybe I can do so somehow?), but… I’ll reread, thanks. As for the “good reason”, it fails me honestly?
s
You can 
export 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.
c
Thanks! I do like the python approach though - everything is touchable but if you get burned don’t blame anyone but yourself.
f
If you’re working in the context of the same pulumi program, you shouldn’t need 
.get
for resources you created in that program.
If you’re trying to reference resources you created in one stack (Stack A) from a different stack (Stack B)
you should export the resources from Stack A (via exports) and use StackReference to retrieve the values in Stack B
So you shouldn’t ever need to care about the way pulumi adds the suffix
If there’s some other use case where you do, I’d be interested in hearing more. In general, 
.get
is intended to help bridge non-pulumi resources that are already there
c
Assume the resources are not created by me, that someone else, some time, created them and I have no control of their stacks or code. That means they must be treated as “already there”.
Is pulumi only intended for very very small organisations where the code is controlled only by a very very small group of people engineering very very small solutions? If so it makes sense, if not… no.
f
Nope, that’s definitely not the intention. But, within a large organization, there’s nothing stopping you from referencing the stacks of some other team.
You likely want to do that from a referencing perspective because if you’re doing it via 
.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.
Open in Slack
PreviousNext
Powered by