This message was deleted.

I believe stack and project names are limited to alphanumeric characters, underscores, hyphens and dots. Is there something specific that you think you may be running into?

Yes. I have a project named

lab

, where I may have different lab environments regionally. So I named the stack

us-west-2

, after the AWS region where it is being deployed. I'm consistently getting an error that doesn't make sense (S3 access permissions). I can't replicate the S3 access permissions error with a different project.

There are restrictions on Pulumi stack and project names, but both

lab

and

us-west-2

would be considered valid. I would guess that the S3 access permission error is somehow related to the way the AWS resources are getting created. Can you share the specific permission error?

Here's the error:

error: failed to load checkpoint: blob (code=Unknown): AccessDenied: Access Denied
	status code: 403, request id: 330331D05850796F, host id: ErSNbu6pMMplveK/evfAlQkzVsbxya8ROQA2e6yt0PlKUI5cLqsFbYdTX0A1xaXmrbMOaBOq+Wk=

I'm using S3 to store the Pulumi stack/state information, and I have some cross-account permissions applied to the S3 bucket. Other projects work fine with this configuration, but this project reports the above error. I'm also trying to determine if this is related to Pulumi 1.3.0.

I think I know the issue. Let me see if I understand what you are doing: 1. You can

pulumi up

the stack just fine. 2. You edit Pulumi.yaml and change the

name

field (i.e. change the project name) 3. You run

pulumi up

and get that error Is that what you are seeing?

Nope. I have never been able to run

pulumi up

, I've received the error above from the very beginning.

So the thing to be aware of is that the “project name” from

Pulumi.yaml

is part of the stack’s identity (at least for the Pulumi Service, and not when using the local backend.) So if you make changes to Pulumi.yaml, it can lead to errors where the stack you are referring to isn’t found. I am not 100% sure the behavior when using the S3 filestate backend. But it could be the case that you need to run

stack init

first, since that 403 could be that the S3 bucket it is trying to read the checkpoint file from doesn’t exist or something.

Using

aws s3 ls

, I can see that the checkpoint file (found at

.pulumi/stacks/us-west-2.json

) does exist, FWIW. I'll try

stack init

and see if that helps, though.

It wouldn’t surprise me if there was some subtle bug here, as the mechanics of “the currently selected stack” and the “file state backend” are kinda complicated. So if you can reproduce this, please do file a bug. (And sorry for the trouble!)

Will do. (And no worries!)