https://pulumi.com logo
Join Slack
Powered by
This message was deleted.
# general
s
This message was deleted.
g
Copy code
error: unexpected duplicate resource 'urn:pulumi:test::aws-eks-py::aws:iam/role:Role$aws:iam/rolePolicyAttachment:RolePolicyAttachment::test-arn:aws:iam'
like, seriously…>? app.pulumi.com blindly allowed this to happen some how and now I don’t know how to get back the old stack version on thei hosted version. S3 would be easy I’d just go to previous object versions
I was able to manually export the stack and remove the duplicates — but this seems like a problem if the stack is removed from the UI, but after renaming it, pulumi (on the app/hosted side) grabs an old stack and merges them or whatever it’s doing
hmm now I’m getting weird panics
guess I am going to have to manually remove all the resources marked for deletion,k and manually reimport them.. what a mess
f
How did you perform the rename? You should get an error from 
pulumi stack rename
along the lines of 
error: [409] Conflict: A stack named projectname/stackname already exists
I’d definitely be interested in making sure we don’t allow renames that end up in the state you described.
Separately, if you’re using app.pulumi.com, for a stack, you can always go to the activity tab, open the details for a previous update, and you’ll see a Download button on the right that allows you to download that particular state.
g
that’s exactly how I renamed it
but the problem is, once it’s renamed the “old stack” disappears from both the UI and CLI so I can’t even pull a previous version of the old name
I used to have a stack called 
test
and I renamed 
test-v2
-> test after previously removing the 
test
stack from the same project.
I feel like Pulumi doesn’t check for this edge-case, and merged my stack state with an old junk version of 
test
lying around on the app’s filestore
that’s how I have all these duplicates
like I said, in S3 land, I would just revert to the previous stack but alas I cannot since 
test-v2
got obliterated from the UI and the usable CI aftter performing the rename, so I can’t even force re-import a version of 
test-v2
state back in even if I wanted to
bad edge case is bad @faint-table-42725 😛
I should have known better and not attempted to rename that back to a previously deleted stack 🤷
now I have a 2 hour shitshow of manually re-importing shit since I can’t get access to the old version easily
f
Sorry to hear this and thanks for the feedback here on the inability to see the stack as it was previously named.
I’ll file a bug on our end to investigate the potential merge behavior. Just to clarify for repro purposes, there used to be a 
test
stack, which you deleted. Then, you had a new stack called 
test-v2
which you then renamed to 
test
and then bad things happened?
g
Yeah. Resources from the old deleted (and then renamed -> to) stack were duplicated some how during the rename.
Copy code
error: unexpected duplicate resource 'urn:pulumi:test::aws-eks-py::aws:iam/role:Role$aws:iam/rolePolicyAttachment:RolePolicyAttachment::test-arn:aws:iam'
I know that’s the case since the old deleted stack was about 1 month older than the test-v2 stack (which I renamed to test) and I recognized the duplicated resources.
so I was like wut?
f
Would it be helpful to try to recover the previous checkpoint for you or are you already past that point?
g
Just to be clear I have renamed stacks before with no issues really, but they weren’t being renamed to a stack name that had previously existed for that particular project.
I think I’m past that point. Out of 88 resources I only had to manually contend with about 6 or 7 of them (delete from stack forcefully, reimport with pulumi import manually).
f
Ok — sorry again for this
g
But it’s something I wanted to bring up since if someone else ran into it, with a stack that had hundreds of resources… it would suck.. a lot
also what’s super interesting the ONLY resources that got duped some how were of this type:
aws:iam:RolePolicyAttachmet
not sure if that helps pinpoint this
er
aws:iam:RolePolicyAttachment
aws provider — not even sure why that would matter, but it didn’t seem to dupe a lot of the others
f
Interesting. Thanks for that additional piece of information
g
either way, smells like somehow pulumi got a hold of a previous state file for the deleted (test) stack, and then attempted to be smart and merge it back in during the rename
if I do get some time I might try replicating this in a lab set up
It’s just hard for me to reproduce, beyond the action part, since I am not hosting app.pulumi.com 😄
for future mental note though, I will definitely be doing a 
pulumi export
before I rename any stacks on app.puluim.com just so I have a copy in case 😉
makes me wonder if the tool should do this too
this was typical terraform behavor when doing things like moving things around in the state, it wold dump a tfstate backup file even if the remote state provider was S3, terraform cloud, etc, just for safety.
f
That’s great feedback as well!
g
I’m back in order now just a update. was able to run a full pulumi refresh and update with the changes
f
g
Yep that would actually be sufficient IMO
that way if things got weird, I could still force re-import the “dumped state” back into the destination renamed stack
Oh yea I commented — might be good to also have 
pulumi stack rm
do the same.
I know there’s a confirmation, if a user uses -y or --force, .. well… I mean, yeah let’s blame them for being dumb, but it’s a good idea to spit that exported state out locally and let them decide to clean it up… and maybe have a flag to override this I dunno. I’m not in the camp of protecting people from themselves all the time, but states are just so sensitive, important and integral to the operation of pulumi, that having a backup of a backup and extra safety checks for this seems fine to me.
I break down stacks into smaller components on purpose because of this (lessons learned from terraform), but not everyone does or can and some stacks can get big, and fingers get twitchy and before you know it… user just killed all their infra state
and app.pulumi.com is not very forgiving about letting me to see a deleted stack
🙂
f
Thanks for the suggestions and good feedback on the service, which I’ve also recorded in our internal issue tracking for that as well.
g
thanks Lee! have a great rest of your day too!
125 Views
Open in Slack
PreviousNext
Powered by