https://pulumi.com logo
#general
Title
# general
b

boundless-monkey-50243

06/10/2019, 7:45 PM
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

handsome-actor-1155

06/10/2019, 7:49 PM
const stackRef = new pulumi.StackReference("accountname/foo-deploy/dev");
b

boundless-monkey-50243

06/10/2019, 7:50 PM
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

handsome-actor-1155

06/10/2019, 7:54 PM
Not sure about s3, tbh. Sorry!
b

boundless-monkey-50243

06/10/2019, 7:55 PM
doh. Thanks though. I was told by @white-balloon-205 it was doable sometime last week, just have to find the magic words
w

white-balloon-205

06/10/2019, 8:39 PM
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

boundless-monkey-50243

06/11/2019, 2:16 PM
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

white-balloon-205

06/11/2019, 3:31 PM
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

boundless-monkey-50243

06/11/2019, 4:22 PM
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

shy-receptionist-99213

06/11/2019, 5:47 PM
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

boundless-monkey-50243

06/11/2019, 6:21 PM
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

shy-receptionist-99213

06/11/2019, 6:40 PM
Looks like
name
from pulumi.yaml is not used for file location, similar to pulumi backed where it's used for namespacing.
b

boundless-monkey-50243

06/11/2019, 6:43 PM
I was wondering about that, yeah. I wonder if that's not the easiest solution? (Though it'll break existing s3 users.)
s

shy-receptionist-99213

06/11/2019, 6:44 PM
Some migration can be provided ( as terraform does this )
👍 1
b

boundless-monkey-50243

06/11/2019, 6:57 PM