-
Notifications
You must be signed in to change notification settings - Fork 192
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
Introduce ex livefs
for layering newly added packages 🗱
#652
Conversation
Demo:
|
This looks great! It will be very useful for projectatomic/atomic#767 |
will it be possible to support removal of an rpm as well? I am asking as that would be helpful for supporting containers update here. |
☔ The latest upstream changes (presumably 710ea30) made this pull request unmergeable. Please resolve the merge conflicts. |
Nice, thanks clang! |
3e5184f
to
3018e3d
Compare
🆕 commits.
Also, a fun twist: |
☔ The latest upstream changes (presumably 19b093e) made this pull request unmergeable. Please resolve the merge conflicts. |
☔ The latest upstream changes (presumably 1c42102) made this pull request unmergeable. Please resolve the merge conflicts. |
30a139b
to
7c178d0
Compare
☔ The latest upstream changes (presumably 75d91a1) made this pull request unmergeable. Please resolve the merge conflicts. |
There are a few different use cases here. First, for layering new packages, there's no good reason for us to force a reboot. Second, we want some support for cherry-picking security updates and allowing admins to restart services. Finally, at some point we should offer support for entirely replacing the running tree if that's what the user wants. Until now we've been very conservative, but there's a spectrum here. In particular, this patch changes things so we push a rollback before we start doing anything live. I think in practice, many use cases would be totally fine with doing most changes live, and falling back to the rollback if something went wrong. This initial code drop *only* supports live layering of new packages. However, a lot of the base infrastructure is laid for future work. For now, this will be classified as an experimental feature, hence `ex livefs`. Part of: #639 Closes: #652 Approved by: jlebon
💔 Test failed - status-atomicjenkins |
Hmm, looks like the
|
assert_livefs_ok | ||
vm_rpmostree ex livefs | ||
vm_cmd rpm -q foo test-livefs-with-etc > rpmq.txt | ||
assert_file_has_content rpmq.txt foo-1.0-1 test-livefs-with-etc-1.0-1 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually, looking at the test output now, I just realized assert_file_has_content
doesn't actually handle arguments past $2
.
For a future patch.
There are a few different use cases here. First, for layering new packages, there's no good reason for us to force a reboot. Second, we want some support for cherry-picking security updates and allowing admins to restart services. Finally, at some point we should offer support for entirely replacing the running tree if that's what the user wants. Until now we've been very conservative, but there's a spectrum here. In particular, this patch changes things so we push a rollback before we start doing anything live. I think in practice, many use cases would be totally fine with doing most changes live, and falling back to the rollback if something went wrong. This initial code drop *only* supports live layering of new packages. However, a lot of the base infrastructure is laid for future work. For now, this will be classified as an experimental feature, hence `ex livefs`. Part of: coreos#639
This is what caused the merge of coreos/rpm-ostree#652 to blow up, since ostreedev#848 landed right before we tried to merge it. When I was writing that PR I remember having an uncertain feeling since we were doing a `mkdirat` above, but at the time I thought we'd have test suite coverage...turns out we didn't. For backwards compatibility, we need to continue to do a `mkdirat` here of the parent. However...I can't think of a reason anyone would *want* that behavior. Hence, let's add a special trick - if the destination name is `.`, we skip `mkdirat()`. That way rpm-ostree for example can open a dfd for `/etc` and avoid the `mkdir`. Fold the subpath tests into `test-basic.sh` since it's not worth a separate file. Add a test case for checking out a file.
This is what caused the merge of coreos/rpm-ostree#652 to blow up, since #848 landed right before we tried to merge it. When I was writing that PR I remember having an uncertain feeling since we were doing a `mkdirat` above, but at the time I thought we'd have test suite coverage...turns out we didn't. For backwards compatibility, we need to continue to do a `mkdirat` here of the parent. However...I can't think of a reason anyone would *want* that behavior. Hence, let's add a special trick - if the destination name is `.`, we skip `mkdirat()`. That way rpm-ostree for example can open a dfd for `/etc` and avoid the `mkdir`. Fold the subpath tests into `test-basic.sh` since it's not worth a separate file. Add a test case for checking out a file. Closes: #854 Approved by: jlebon
Ok, fixup ⬆️ |
For a future patch. Closes: #652 Approved by: jlebon
There are a few different use cases here. First, for layering new packages, there's no good reason for us to force a reboot. Second, we want some support for cherry-picking security updates and allowing admins to restart services. Finally, at some point we should offer support for entirely replacing the running tree if that's what the user wants. Until now we've been very conservative, but there's a spectrum here. In particular, this patch changes things so we push a rollback before we start doing anything live. I think in practice, many use cases would be totally fine with doing most changes live, and falling back to the rollback if something went wrong. This initial code drop *only* supports live layering of new packages. However, a lot of the base infrastructure is laid for future work. For now, this will be classified as an experimental feature, hence `ex livefs`. Part of: #639 Closes: #652 Approved by: jlebon
💔 Test failed - status-atomicjenkins |
@rh-atomic-bot retry |
There are a few different use cases here. First, for layering new packages, there's no good reason for us to force a reboot. Second, we want some support for cherry-picking security updates and allowing admins to restart services. Finally, at some point we should offer support for entirely replacing the running tree if that's what the user wants. Until now we've been very conservative, but there's a spectrum here. In particular, this patch changes things so we push a rollback before we start doing anything live. I think in practice, many use cases would be totally fine with doing most changes live, and falling back to the rollback if something went wrong. This initial code drop *only* supports live layering of new packages. However, a lot of the base infrastructure is laid for future work. For now, this will be classified as an experimental feature, hence `ex livefs`. Part of: #639 Closes: #652 Approved by: jlebon
☀️ Test successful - status-atomicjenkins |
Great! When the next release ?=) @cgwalters |
This is a de-scoping of work I did in preparation for rpm-ostree [live updates](coreos/rpm-ostree#652). Originally I was going to expose this as a public API. However, I decided to do things differently, but the cleanup here for new code style and fd-relative is nice to have anyways. We rework things to use `OstreeDeployment*`, which the caller is expected to already have, rather than `GFile*`s pointing to the config directories.
This is a de-scoping of work I did in preparation for rpm-ostree [live updates](coreos/rpm-ostree#652). Originally I was going to expose this as a public API. However, I decided to do things differently, but the cleanup here for new code style and fd-relative is nice to have anyways. We rework things to use `OstreeDeployment*`, which the caller is expected to already have, rather than `GFile*`s pointing to the config directories. Closes: #741 Approved by: jlebon
WIP due to missing tests and docs.
But I've been playing with this interactively, and it's at a useful place
already. The primary target here is supporting live addition of new packages,
while also allowing people to do completely arbitrary replacement if that's
what they want.
Depends:
Closes: #639