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

daemon: Retain pinned deployments #1309

Closed
wants to merge 1 commit into from

Conversation

cgwalters
Copy link
Member

Followup to: ostreedev/ostree#1464

Ideally, we'd delegate more logic around these things to libostree, but we're
not there yet.

This means e.g. rpm-ostree cleanup -r for a pinned rollback will just silently
skip it. It'd be nicer to emit an error probably, but that'd be quite a bit
more work.

Closes: #1293

Followup to: ostreedev/ostree#1464

Ideally, we'd delegate more logic around these things to libostree, but we're
not there yet.

This means e.g. `rpm-ostree cleanup -r` for a pinned rollback will just silently
skip it.  It'd be nicer to emit an error probably, but that'd be quite a bit
more work.

Closes: coreos#1293
@dustymabe
Copy link
Member

What about #577 ?

@matthiasclasen hit something today that fixing #577 could have prevented I think.

@cgwalters
Copy link
Member Author

This PR is just finishing out the implementation of the pinning approach. I personally think it mostly addresses the issue, but if you feel there's still a need for the "configure number" approach it's fine to leave the issue open, though I can't say implementing it is going to be anywhere near the top of the list soon for me personally.

@jlebon
Copy link
Member

jlebon commented Mar 23, 2018

LGTM. Seems safe enough to include in the next release.
@rh-atomic-bot r+ c466377

@rh-atomic-bot
Copy link

⚡ Test exempted: pull fully rebased and already tested.

cgwalters added a commit to cgwalters/rpm-ostree that referenced this pull request Mar 23, 2018
In this PR: coreos#1309
I was hitting race conditions running `ostree admin pin` then
`rpm-ostree cleanup` as it was possible that the daemon hadn't handled
the inotify on the sysroot and reloaded the deployment state before
the txn request came in.

Close this race by doing an implicit `reload` before starting a txn.
This is a pretty efficient operation because for the sysroot we're
just doing a `stat()` and comparing mtime.

Implementation wise, change the external API to drop the "did change"
boolean as nothing outside of the `sysroot.c` file used it.

A followup to this would be changing the `status` CLI to call a
(new) DBus API like `RequestReload` that at least did the sysroot
reload if the daemon was otherwise idle or so?  And it'd be available
to unprivileged users.
cgwalters added a commit to cgwalters/rpm-ostree that referenced this pull request Mar 23, 2018
In this PR: coreos#1309
I was hitting race conditions running `ostree admin pin` then
`rpm-ostree cleanup` as it was possible that the daemon hadn't handled
the inotify on the sysroot and reloaded the deployment state before
the txn request came in.

Close this race by doing an implicit `reload` before starting a txn.
This is a pretty efficient operation because for the sysroot we're
just doing a `stat()` and comparing mtime.

Implementation wise, change the external API to drop the "did change"
boolean as nothing outside of the `sysroot.c` file used it.

A followup to this would be changing the `status` CLI to call a
(new) DBus API like `RequestReload` that at least did the sysroot
reload if the daemon was otherwise idle or so?  And it'd be available
to unprivileged users.
rh-atomic-bot pushed a commit that referenced this pull request Mar 23, 2018
In this PR: #1309
I was hitting race conditions running `ostree admin pin` then
`rpm-ostree cleanup` as it was possible that the daemon hadn't handled
the inotify on the sysroot and reloaded the deployment state before
the txn request came in.

Close this race by doing an implicit `reload` before starting a txn.
This is a pretty efficient operation because for the sysroot we're
just doing a `stat()` and comparing mtime.

Implementation wise, change the external API to drop the "did change"
boolean as nothing outside of the `sysroot.c` file used it.

A followup to this would be changing the `status` CLI to call a
(new) DBus API like `RequestReload` that at least did the sysroot
reload if the daemon was otherwise idle or so?  And it'd be available
to unprivileged users.

Closes: #1311
Approved by: cgwalters
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants