https://pulumi.com logo
Join Slack
Powered by
Related to a prior question - how does one tell a ...
# general
b
Related to a prior question - how does one tell a 
pulumi.StackReference
to look at a stack in another S3 bucket, by stack name? i.e., I’m in 
bar-deploy
, I need to access 
foo-deploy
, but I need to specifically get outputs from the 
dev
stack (use case: there might be multiple 
bar-deploy
stacks using 
foo-deploy
@ 
dev
as their backend). How can I express this?
h
const stackRef = new pulumi.StackReference("accountname/foo-deploy/dev");
b
How’s that work with S3 buckets, though?
(I saw you were the other person asking around about this the other day, ha)
Like, say my target is `s3://pulumi-foo-deploy`; how do I get the 
dev
stack from it? 
<s3://pulumi-foo-deploy/dev>
doesn’t work.
I get 
NotFoundKey
errors, so it’s looking for something, just can’t find it. Next stop is CloudTrail I guess. 😧
h
Not sure about s3, tbh. Sorry!
b
doh. Thanks though. I was told by @white-balloon-205 it was doable sometime last week, just have to find the magic words
w
I think I would have expected that to work as written (assuming a stack by that name exists in the same S3 backend). If you verify that stack does exist but isn’t being looked up here - could you open an issue so we can investigate?
b
Wait. I think we're using different definitions of "the same backend".
I take it to mean "the same S3 account, accessed with the same S3 credentials". No?
If it's "literally the same `pulumi login`'d stack", then that's going to be a real problem and I'm gonna look like an idiot. 😕
w
Could you describe the full scenario you are looking to enable? I'm not sure I follow why you would want/need to have different `pulumi login`s for the same S3 bucket? In general, at least currently, the backend you are logged into is the context for discovering and referencing all the stacks that you have available.
b
I am looking to allow somebody in, for example, the 
app-deploy
workspace to be able to acquire data out of, say, the 
network-base
workspace, keyed to a particular stack.
Having read-write to 
app-deploy
does not imply write access to 
network-base
, regardless of environment (Pulumi stack) being worked on.
I don't really want to use prefixes inside of a single 
.pulumi
directory because it 1) makes for (what I think are) less comprehensible IAM policies, and 2) means then that my developers have to remember--and they will not remember--to do stuff like 
pulumi stack some-app/dev
in their working directories, rather than 
pulumi stack dev
. If it helps, the analogy I'm looking for is to separate 
terraform.tfstate
files.
I want my application to be able to go "I'm a 
dev
stack! I'm going to look for the 
dev
stack in 
network-base
and find out my VPC CIDR block!".
(I could be totally misunderstanding something clever, to be clear. If so, maybe it's useful as something to underline in the docs. 😉 )
s
we’re also lookign for the same solution. For example infrastructure team uses 
pulumi login <s3://some-bucket/infra>
and services have 
pulumi login <s3://some-bucket/service>
. How do we reference 
infra
from 
service
ones?
b
That's a good point, and it hits on at having a single 
pulumi login
at a system level, too. This feels like it should be per-directory.
@white-balloon-205 As an example of why this is gross, if everything's in a single stack repo, I have to tell my developers to do stuff like 
pulumi stack switch dev.deploy.data-api-v2
and to be aware of eye-popping files like 
Pulumi.dev.deploy.data-api-v2.yaml
. Admittedly this might be a little vain, but that's just really unpleasant to be throwing in a repo when the file itself lives in 
data-api-v2/deploy
(because we also have a 
data-api-v2/build
Pulumi...I keep wanting to call them stacks...workspace?...that contains our CodeBuild, CodePipeline, etc. definitions) .
It just really doesn't feel like the single-namespace model holds up at moderate scale.
s
Looks like 
name
from pulumi.yaml is not used for file location, similar to pulumi backed where it's used for namespacing.
b
I was wondering about that, yeah. I wonder if that's not the easiest solution? (Though it'll break existing s3 users.)
s
Some migration can be provided ( as terraform does this )
👍 1
b
Open in Slack
PreviousNext
Powered by