-
Notifications
You must be signed in to change notification settings - Fork 196
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
Conversation
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
What about #577 ? @matthiasclasen hit something today that fixing #577 could have prevented I think. |
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. |
LGTM. Seems safe enough to include in the next release. |
⚡ Test exempted: pull fully rebased and already tested. |
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.
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.
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
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 silentlyskip it. It'd be nicer to emit an error probably, but that'd be quite a bit
more work.
Closes: #1293