Hi folks - bit of a pickle here. We downgraded one...
# getting-started
m
Hi folks - bit of a pickle here. We downgraded one of our customers from enterprise to team edition recently because credits are much cheaper and its' been nothing but a nightmare since. The stacks don't seem to be even working (stack names have somehow changed to "orgName/stackName" instead of "stackName" because our access tokens are now PATs and not the org token when accessing via token). How do we transition to accessing our org stacks via PAT without a full blown deletion and/or ownership transfer to personal accounts? This is especially a problem for us because now that the stack names somehow have a "/" in them, we are no longer able to point them to an ESC ENV via a "pulumi..../.yaml" file
c
When using PATs the stack name defaults to using the personal account name of the user to whom the token belongs. You just need to make sure to use the fully-qualified stack name in your stack commands. That is, orgName/stackName whenever you are referring to a stack that is in an org and not in a personal org.
m
@clever-sunset-76585 the issue with that, as outlined above, is that we can't have a file name with a dash in it for the stack-specific YAML config
looking for a possible workaround for that
Maybe we're just missing something obvious in the docs 😞
c
is that we can't have a file name with a dash in it for the stack-specific YAML config
That's not how that works though. The stack config filenames just have the name part always regardless of where the stack exists, i.e. personal or a shared org. So to resolve ambiguity when targeting a stack, you should
pulumi up -s <org>/<stack>
. In fact, the actual fully-qualified name for a stack also includes its project name, so it's actually
<org>/<project>/<stack>
. However, the CLI detects the project name. from the working dir's
Pulumi.yaml
file and fills that in implicitly.
m
^ This helps a lot. Thank you very much! Not sure how we missed that.