Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bootc status without sysroot lock #585

Open
p5 opened this issue Jun 4, 2024 · 2 comments
Open

Bootc status without sysroot lock #585

p5 opened this issue Jun 4, 2024 · 2 comments
Labels
area/cli Related to the client/CLI bug Something isn't working enhancement New feature or request

Comments

@p5
Copy link

p5 commented Jun 4, 2024

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 cgwalters added bug Something isn't working enhancement New feature or request area/cli Related to the client/CLI labels Jun 4, 2024
@cgwalters
Copy link
Collaborator

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.

@cgwalters
Copy link
Collaborator

cgwalters commented Jun 20, 2024

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

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/cli Related to the client/CLI bug Something isn't working enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants