millions-train-91139
03/17/2023, 2:42 PMsalmon-account-74572
03/17/2023, 3:24 PMmillions-train-91139
03/17/2023, 3:43 PMacme-monolith
) and same target project (acme-only-db
) but the stacks are different (3 + no_of_devs).
And obviously “imports” should be on a per stack basis
I stumbled upon pulumi state export/import
but what I didn’t like is:
1. Huge json that is hard to look at manually to select resources - probably a interactive git like command line where you select which resources you want could have made my life easier (might write one)
2. Need to also search and replace urn:pulumi:acme-monolith-1::acme-monolith
with urn:pulumi:acme-db-only-1::acme-db-only
- but its fairly easy
3. Need to pulumi stack change-secrets-provider default
to resecret everything - but its fairly easy
4. Need to rm -f
complement resources from source stack states
5. Need to make sure the code everyone uses for pulumi up -s acme-monolith
stops creating the resources that moved to the new stack - but if I just removes those resources from the code, and the code runs before the states migrates, then the resources will be deleted (😱 our dbs) so probably we need to add retainOnDelete
in the old stacks and tell everyone to pulumi up
on all stacks. But we don’t want retainOnDelete
in the new stack - so there’s are multiple deployment waves that we have to synchronize for such a small thing that we want to do
6. pulumi state import
is not previewable and I’m not sure how to set a correct security/organizational 4-eye+ policy for reviewing such horrific changes
Well I tried doing something awful like:
1. pulumi state export --file export.json
2. jq operations to make export.json become valid for pulumi import
operation which is reviewable
3. pulumi import that json, but it crashes since obviously this is not meant to be
Feels like tooling is missing on client side - can be fixed by each org doing its own shtick
But probably there also work that has to be done on the backends in order to support migration more natively - to prevent a resource existing in two stacks at once
(like we have today when we migrate entire pulumi stacks between orgs in app.pulumi.com)salmon-account-74572
03/17/2023, 3:58 PMjq
(as you discovered) to work with resources in the state export file. To assist with building jq
queries, you might try jid
(JSON incremental digger, I believe it what it stands for). Very helpful when you aren’t 100% familiar with the schema of whatever JSON you’re working with.
• WRT to your points 4 and 5, you can use pulumi state delete
to remove objects from state, then refactor the code to remove those resources. Then running pulumi up
should result in a no-op (no changes), because the program and the state match. But yes, you do want to ensure no one runs pulumi up
between updating the state and refactoring the code. The --target-dependents
flag for pulumi state delete
might make it easier, if a lot of the resources fall under a comment parent resource.
• And as far as no preview for the state import function---yep, you’re 100% correct. It’s one of the reasons this process/procedure is unsupported.
You could consider a process like this:
1. Remove the resources from the original project/stack using pulumi state delete
and refactor code to no longer create those objects. They now exist on the cloud provider, but are not under Pulumi management.
2. Use pulumi import
to re-import those objects back into Pulumi, generating code along the way. Compare this to the code you removed in step 1 to make sure things line up.
This is also not without its caveats, but it is a more supported procedure.
We (Pulumi) do recognize there’s a gap here, and we’ve started thinking about how to address this. I don’t know if there’s an issue already open for tracking; if I find one, I’ll add it here and we’d love to hear your thoughts on how you think it should work/function.millions-train-91139
03/17/2023, 4:00 PMsalmon-account-74572
03/17/2023, 4:06 PMmillions-train-91139
03/17/2023, 4:15 PMpulumi state import/export
only edits text files and doesn’t really changes resources. Subsequent pulumi up
might be affected but at least they will go through 4-eye review policy
2. Pulumi’s backend keeps history - we can download older state if something goes horribly wrong
I also think that you are correct that if we do a “stop the world” event at our org and synchronize everything - it will be okay.
But some dev stacks might be in some inconsistent state and might require some time to fix back into a `pulumi up`able state, which sometimes might make this event longer that it should be - in addition it’s not always clear how you “go back”.
Also, if assuming the worst, where everything happens async. I think this is the correct flow:
1. Block pulumi up
2. Remove the code in the code base (4eye review)
3. Make sure nobody `pulumi up`s the old code (4eye review anyway)
4. Delete the state from all stacks manually - write complicated script - no 4 eye policy, no easy way to view changes, required Pulumi proficiency
5. Unblock pulumi up
6. Floating resources should be wrangled back into new stacks - write complicated script - no 4 eye policy, no easy way to view changes, required Pulumi proficiencysalmon-account-74572
03/17/2023, 4:42 PMmillions-train-91139
03/18/2023, 9:51 AM-u
flag
I need it for filtering the state importsgreen-stone-37839
03/18/2023, 1:39 PMlittle-cartoon-10569
03/19/2023, 7:11 PMpulumi state import
base tool will always stay, like a git porcelain command; being able to completely overwrite the state has save me so much work in the past, it can never go away!
(It's amazing for a complete rebrand of projects, stacks and resource names; a few search-and-replaces on a copy of your state, import it, and you've got a shiny new product!)