<@UB39JFCKC> I noticed that pulumi stores stack hi...
# general
p
@tall-librarian-49374 I noticed that pulumi stores stack history files in blob storage. Is it possible to somehow have pulumi restore infra state with those files? like lets say something fails to builds and you need to roll back.
t
blob storage is one of the options. I’m not super familiar with it - others can help.
g
Pulumi always drives toward your code, not your state. The state is used to help determine the "diffs" for resources and mapping your resource in code to the resources in the cloud, but the code is what determines the "what" to do. So, to do a rollback in Pulumi, you would rollback/revert your code (and config) and do an
up
from that.
p
Gotcha, I was just trying to honestly figure out what the state history files were for since it seems to like to keep those around for a while
b
Somebody correct me if I'm wrong, but I believe that information is kept for this command: https://www.pulumi.com/docs/reference/cli/pulumi_stack_history/
but AFAIK it is more of an audit-log than something you could revert to because as @gentle-diamond-70147 said your pulumi code is in source control so you would just revert that
p
gotcha gotcha
l
Does kinda make sense to make it so the history can be used to roll back (thinking of how Helm and Kubectl provide a rollback feature)
But I guess that means defining an inverse operation for everything, and probably defaulting to not deleting resources
Although, I guess Pulumi would just act as if its applying the rolled back state on top of the current and diff as normal
b
Agree to disagree. Since your code is a representation of desired state, your code should never differ from what is desired. So if you need to rollback, than your desired state has changed, and thus you should simply change your code and pulumi up again A pulumi rollback is just going with a previous commit of your pulumi code
If you could rollback from pulumi stack history, than your desired state and your code would go out of alignment
p
In that case it seems like a waste formPuljmi to keep so many stake state historic files.
b
There is value in having an audit log of changes made to your cloud infrastructure, independent of any roll back requirements. It’s still marked as being in preview and currently there isn’t any retention configuration mechanism but if you control the state files you could easily truncate them yourself.
p
That’s a good point.