You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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 #2 in that if we were a daemon it'd be much easier to manage concurrency.
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.
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.
The text was updated successfully, but these errors were encountered: