Keep 2 basecommits around during rpm-ostree mutations

[dustymabe]

User Story:

• As a user I'd like to be able to do an upgrade and then package
  layer a few rpms without losing the original 'pre-upgrade'
  deployment.

Example Steps:

• start at deployment X
• rpm-ostree upgrade (upgrades to new commit and deployment Y)
• reboot (into deployment Y)
• rpm-ostree install strace (creates new deployment Z - keeps around X)
• reboot (into deployment Z)
• rpm-ostree deploy X
• reboot
• back to X (would this preserve files in /etc/ ?????)

Basically we view deployment Z as a variation of Y and it would be
great to be able to go back to X.

[cgwalters]

Related to /etc, yes, we'd be using the new /etc with any changes you made while booted into Z.

Your user story here still seems a bit too implementation-y. Why do you want the original pre-upgrade deployment? Something like finding a problem in Y that isn't related to the packages from Z?

[cgwalters]

Is this more like "always keep around a non-layered deployment? I can imagine a policy of going from 1 → 2 retained is simple to explain/implement though. In the end remember a goal is that one can use rpm-ostree deploy to re-retrieve old versions. Would it help to log to the journal the base tree versions and render a bit of the deployment history in rpm-ostree status?

[dustymabe]

Related to /etc, yes, we'd be using the new /etc with any changes you made while booted into Z.

was hoping we could actually preserve the capability to rollback to /etc/ from the time before the Y upgrade

Your user story here still seems a bit too implementation-y. Why do you want the original pre-upgrade deployment? Something like finding a problem in Y that isn't related to the packages from Z?

Right, one example is that I upgrade to Y and package layer to get to Z very quickly and didn't realize there was actually an issue with Y until I was already at Z. This is sloppy on the part of the sys-admin, but could happen.

Is this more like "always keep around a non-layered deployment?

kind of, basically keep 2 "basecommits" around (basecommit vs subcommit as described in #812)

I can imagine a policy of going from 1 → 2 retained is simple to explain/implement though. In the end remember a goal is that one can use rpm-ostree deploy to re-retrieve old versions.

yeah, since subcommits probably aren't large compared to the basecommits i think it would be nice to keep around 2 of the basecommits and also be able to rollback to any of the deployments that we have on the system (rpm-ostree rollback X from the example in description). rollback meaning we do actually revert state in /etc/. If someone wants to preserve state in /etc/ they could deploy instead.

Would it help to log to the journal the base tree versions and render a bit of the deployment history in rpm-ostree status?

yes, i think this would be very useful. kind of like dnf history list. Maybe would be best to put that info in a separate history subcommand. Want me to open an issue for that?

[jlebon]

This would be addressed by ostreedev/ostree#1960, which... yeah we need to push that through.