https://pulumi.com
Join Slack
This message was deleted.
# general
s
This message was deleted.
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

Pulumi Community

No matter how you like to participate in developer communities, Pulumi wants to meet you there. If you want to meet other Pulumi users to share use-cases and best practices, contribute code or documentation, see us at an event, or just tell a story about something cool you did with Pulumi, you are part of our community.

Powered by