upgrader: Use "pending" deployment for origin by default #611
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
If we agree on this I'll do the tests. |
|
Yeah, I think that makes sense overall. We'll need to remember to note the backwards incompatibility at release time, even though the new behaviour is probably what most people want. |
cgwalters
force-pushed
the
auto-resume
branch
from
ce70c55
to
afc16f0
Compare
|
Rebased 🏄 and with tests ☑️ |
jlebon
reviewed
Feb 8, 2017
|
|
||
| # rollup: install/deploy/uninstall | ||
|
|
||
| assert_status_jq ".deployments[0][\"base-checksum\"] == \"${commit}\"" \ |
There was a problem hiding this comment.
Ahh, I renamed this to vm_assert_status_jq in my last PR. :)
jlebon
reviewed
Feb 8, 2017
| '.deployments[0]["packages"]|index("nonrootcap")|not' | ||
| vm_rpmostree install nonrootcap | ||
| assert_status_jq ".deployments[0][\"base-checksum\"] == \"${commit}\"" \ | ||
| '.deployments[0]["packages"]|index("foo") >= 0' \ |
There was a problem hiding this comment.
I think there's an has() operator that would be nice here.
There was a problem hiding this comment.
Doesn't do what you'd think:
echo '["foo", "bar"]' | jq 'has("foo")'
jq: error (at <stdin>:1): Cannot check whether array has a string key
I looked but didn't see a jq operator for searching an array.
Until now, we always used the booted deployment, and would garbage collect the "pending" deployment. This is the way OSTree was designed, but I think for rpm-ostree given how mutable we are on the client side, there's a much stronger argument for being more stateful too. This is a relatively simple code change to split the "merge deployment" concept into two. There's now the "config merge deployment" and the "origin merge deployment". Basically, `rpm-ostree install foo; rpm-ostree install bar` will now install both `foo` and `bar`. But we will still use the booted deployment for `/etc`. Down the line, I think I'd like to drive into OSTree the concept of a "staged" deployment, that has the hardlink checkout done, but doesn't have the config merge. But we don't need to change the OSTree core for this yet; we can do it here in rpm-ostree, and this relatively simple code change fixes many issues at once. For example, `rpm-ostree upgrade && rpm-ostree install foo` now does what you expect as well. Obviously, we want to enable doing multiple things in *one* transaction, and we're not far away, but I think this is also the right thing to do now. I'm relatively confident it won't break anyone's workflow, as what we did before wasn't generally that useful. However, people will need to learn to `ostree admin undeploy 0` if they *don't* want this behavior. (We need to have `rpm-ostree cleanup`). Closes: coreos#406
cgwalters
force-pushed
the
auto-resume
branch
from
afc16f0
to
123a5b6
Compare
|
Rebased 🏄 |
|
☀️ Test successful - status-atomicjenkins |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Until now, we always used the booted deployment, and would
garbage collect the "pending" deployment. This is the
way OSTree was designed, but I think for rpm-ostree given
how mutable we are on the client side, there's a much stronger
argument for being more stateful too.
This is a relatively simple code change to split the "merge deployment"
concept into two. There's now the "config merge deployment" and the
"origin merge deployment".
Basically,
rpm-ostree install foo; rpm-ostree install barwillnow install both
fooandbar. But we will still use the booteddeployment for
/etc.Down the line, I think I'd like to drive into OSTree the concept of
a "staged" deployment, that has the hardlink checkout done, but doesn't
have the config merge.
But we don't need to change the OSTree core for this yet; we can
do it here in rpm-ostree, and this relatively simple code change
fixes many issues at once.
For example,
rpm-ostree upgrade && rpm-ostree install foonowdoes what you expect as well.
Obviously, we want to enable doing multiple things in one transaction,
and we're not far away, but I think this is also the right thing to do now.
I'm relatively confident it won't break anyone's workflow, as what
we did before wasn't generally that useful. However, people will
need to learn to
ostree admin undeploy 0if they don't wantthis behavior. (We need to have
rpm-ostree cleanup).Closes: #406