Looks like if an `up` fails then it doesn't roll b...
# getting-started
s
Looks like if an
up
fails then it doesn't roll back and you need to go into the Azure website to work out what happened and clean up?
g
If an
up
fails, it generally provides a trace that lets you know what happened. If it seems that you need to clean up to get back to a clean slate, it's better to run
pulumi destroy
, which will not only remove the resources but will also clean up the state of the resources in Pulumi. Otherwise, if you go into Azure's dashboard and change things, Pulumi will think things are around which aren't because changing things directly in Azure doesn't fix the state that Pulumi has.
s
So if it fails on something that's live (that you can't destroy because people are using it) then you just have to ditch pulumi because it's all out of synch
g
No, you can modify the state with a
pulumi refresh
, which verifies the state. The implication in your first post was that you wanted to wipe the build and restart, which is a
pulumi destroy
instead of working off of the dashboard. If you're working with a live system with others using it, you want to use
pulumi refresh
and then
pulumi up
to first refresh state (i.e., tell Pulumi what the current state is) and then attempt the change again (i.e., have Pulumi compare the current state to the desired one and request the missing pieces)