Bootc status without sysroot lock

[p5]

When an automated upgrade is happening in the background, you are unable to query bootc status to see information about the current deployment (or to see the upgrade is in progress), since status requires a sysroot lock. I would expect such read-only commands (I can only think of status for now) to not require a system lock, and display the regular output regardless of whether another process is happening.

This could cause some confusion when you're blocked from seeing information about your system due to a command that's invoked without the user saying to do so.

If there's some context I am missing or a technical limitation, I'm more than happy for you to say "this is expected" and close this.

[cgwalters]

This is currently expected, yes. I think the main fix here would be introducing a new lock for "downloading", and we drop the global sysroot lock when we're doing that.

This issue however is very related to https://github.com/containers/bootc/issues/2 in that if we were a daemon it'd be much easier to manage concurrency.

[cgwalters]

Was just thinking about this a bit more, and maybe instead of a distinct downloading lock:

• Change the fetch code to drop the sysroot lock when fetching, and reacquire when doing a deployment
• Add a kube-style "resource version" to our metadata, so that we can detect logical conflicts (edit: and I think we have such a "resource verison" today in the ostree sysroot timestamp, see https://github.com/ostreedev/ostree/blob/0ea7d2e326ebce5ede672c30dec1517b8208ee10/src/libostree/ostree-sysroot.c#L449

If we just did the first part of dropping the lock during fetch, then invoking in parallel in one shell (or systemd unit, etc.) a bootc upgrade and in another a bootc switch, then we'd introduce "last one to finish wins" semantics.

But with the resource version, after reacquiring the lock we'd detect that the world had changed, and bail; so while it'd still be racy (as it is inherently, even with global locking) it'd at least have a more obvious failure mode which I think is what we want here.