Keep metadata from previous trees when purging

[stefwalter]

A UI like Cockpit would like to be able to access metadata about previous versions of the operating system, beyond just the current and last versions. This is especially apparent when performing an update.

• If A -> B -> C are trees.
• I'm running B with A available as a rollback.
• I update to C and reboot.
• B is shown as a rollback but A disappears

It should be possible for a caller of rpm-ostreed to get information about A and offer the user the ability to readily rollback to it. Would it be possible to keep metadata for A, even if the binary data is purged?

I'm aware of the 'rpm-ostree deploy ...' stuff which is great, and should also be wrapped in the UI, but this is an additional part of the story.

[cgwalters]

Sorry about not replying earlier. I'm not fully understanding how this would be used in addition to the deploy verb focus.

There's two levels of metadata:

• The fact that A was deployed
• Commit metadata, traversable via the ostree log

The first thing we actually already log in the systemd journal...no wait, I'm lying. We don't log to the journal because rpm-ostree sets up a hack to capture its own stdout 😢

https://github.com/ostreedev/ostree/blob/4929ab4033894d0aaf1987ebc07d7ccbe23323e1/src/libostree/ostree-sysroot-deploy.c#L1946

After we fix that, we'd also need to teach it to use structured logging to output the deployment information.

But would that architecture work for you? Use the journal to look up structured logging info about previous deployments?

[jlebon]

This is somewhat fixed now by #1813.