I have an expired `databricks:token` stuck in the ...
# general
i
I have an expired
databricks:token
stuck in the config of some of my stacks so I cannot
destroy
them - and I no longer have the source code that was used to bring the stacks up. what's the solution here?
this doesn't quite seem like what you're meant to do, but I've created a new pulumi project with the exact same name & stack name, with a new .yaml config where I've used
pulumi config set --secret
to set the new token, then had to create a blank index.js with a new resource of the same type. After running
up
it seems to update the cached token in the remote stack
Without creating a new resource of the same type (or from the same provider) in index.js, it would still try to use the expired token when deleting resources. Having the new resource there meant that the create tasks were executed first, which must have flushed out the expired token
This is fairly poor DX, there must be a better way to interact with remote state
m
You can fetch the config for an existing project using
pulumi config refresh
i
I did that - and then used
pulumi config set
to provide newer values, but it still kept trying to use the expired token when deleting resources It was only when I created a dummy resource from the same provider, did the "create" task flush out the expired token from the backend
it would be cool if I could do something like: 1.
pulumi stack export > state.json
2. manually edit state.json 3.
pulumi stack import < state.json
oh... it looks like you can! I only knew about step 1
a
Hi @icy-controller-6092 Came across your post while searching for something else. Using the PAT is probably not the best way to do this, since the token expires. We found that the cleanest way to do this was to use
auth_type="azure-client-secret",
and provide the client ID and client Secret as environment variables.