2016-07-04 18:43:02 +03:00
#!/bin/bash
#
# Copyright (C) 2016 Jonathan Lebon <jlebon@redhat.com>
#
# This library is free software; you can redistribute it and/or
# modify it under the terms of the GNU Lesser General Public
# License as published by the Free Software Foundation; either
# version 2 of the License, or (at your option) any later version.
#
# This library is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
# Lesser General Public License for more details.
#
# You should have received a copy of the GNU Lesser General Public
# License along with this library; if not, write to the
# Free Software Foundation, Inc., 59 Temple Place - Suite 330,
# Boston, MA 02111-1307, USA.
2017-10-01 16:34:23 +03:00
set -euo pipefail
2016-07-04 18:43:02 +03:00
. ${ commondir } /libtest.sh
. ${ commondir } /libvm.sh
set -x
# SUMMARY: check that packages get carried over during reployments from
# upgrades, deploys, and rebases.
# METHOD:
# Add a package, then test that after an upgrade, deploy, or rebase, we
# still have the package.
# make sure the package is not already layered
vm_assert_layered_pkg foo absent
2017-06-29 17:11:25 +03:00
vm_build_rpm foo
2017-01-17 21:29:48 +03:00
vm_rpmostree pkg-add foo
2016-07-04 18:43:02 +03:00
echo "ok pkg-add foo"
vm_reboot
vm_assert_layered_pkg foo present
echo "ok pkg foo added"
reboot_and_assert_base( ) {
vm_reboot
basecsum = $( vm_get_booted_deployment_info base-checksum)
if [ [ $basecsum != $1 ] ] ; then
assert_not_reached " new base-checksum does not refer to expected base $1 "
fi
}
# UPGRADE
2017-02-08 01:49:20 +03:00
vm_assert_status_jq \
'.deployments[0]["base-checksum"]' \
'.deployments[0]["pending-base-checksum"]|not'
2016-07-04 18:43:02 +03:00
# let's synthesize an upgrade
commit = $( vm_cmd ostree commit -b vmcheck --tree= ref = vmcheck)
2017-01-17 21:29:48 +03:00
vm_rpmostree upgrade
2017-02-08 01:49:20 +03:00
vm_assert_status_jq \
'.deployments[1]["base-checksum"]' \
'.deployments[1]["pending-base-checksum"]'
2017-01-27 07:31:53 +03:00
vm_rpmostree status --json > status.json
2016-07-04 18:43:02 +03:00
reboot_and_assert_base $commit
2017-02-08 01:49:20 +03:00
vm_assert_status_jq \
'.deployments[0]["base-checksum"]' \
'.deployments[0]["pending-base-checksum"]|not' \
'.deployments[1]["pending-base-checksum"]'
2016-07-04 18:43:02 +03:00
echo "ok upgrade"
vm_assert_layered_pkg foo present
echo "ok pkg foo relayered on upgrade"
# DEPLOY
commit = $( vm_cmd ostree commit -b vmcheck \
--tree= ref = vmcheck --add-metadata-string= version = my-commit)
2017-01-17 21:29:48 +03:00
vm_rpmostree deploy my-commit
2016-07-04 18:43:02 +03:00
reboot_and_assert_base $commit
echo "ok deploy"
vm_assert_layered_pkg foo present
echo "ok pkg foo relayered on deploy"
# REBASE
2017-03-31 16:07:29 +03:00
commit = $( vm_cmd ostree commit -b vmcheck_tmp/rebase_test --tree= ref = vmcheck)
vm_rpmostree rebase --skip-purge vmcheck_tmp/rebase_test
2016-07-04 18:43:02 +03:00
reboot_and_assert_base $commit
echo "ok rebase"
vm_assert_layered_pkg foo present
echo "ok pkg foo relayered on rebase"
upgrader: Use "pending" deployment for origin by default
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: https://github.com/projectatomic/rpm-ostree/issues/406
Closes: #611
Approved by: jlebon
2017-02-08 19:00:18 +03:00
# rollup: install/deploy/uninstall
vm_assert_status_jq " .deployments[0][\"base-checksum\"] == \" ${ commit } \" " \
'.deployments[0]["packages"]|index("foo") >= 0' \
2017-06-29 17:11:25 +03:00
'.deployments[0]["packages"]|index("bar")|not'
vm_build_rpm bar
vm_rpmostree install bar
upgrader: Use "pending" deployment for origin by default
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: https://github.com/projectatomic/rpm-ostree/issues/406
Closes: #611
Approved by: jlebon
2017-02-08 19:00:18 +03:00
vm_assert_status_jq " .deployments[0][\"base-checksum\"] == \" ${ commit } \" " \
'.deployments[0]["packages"]|index("foo") >= 0' \
2017-06-29 17:11:25 +03:00
'.deployments[0]["packages"]|index("bar") >= 0'
upgrader: Use "pending" deployment for origin by default
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: https://github.com/projectatomic/rpm-ostree/issues/406
Closes: #611
Approved by: jlebon
2017-02-08 19:00:18 +03:00
commit = $( vm_cmd ostree commit -b vmcheck \
--tree= ref = vmcheck --add-metadata-string= version = my-commit2)
vm_rpmostree rebase ${ commit }
vm_assert_status_jq " .deployments[0][\"base-checksum\"] == \" ${ commit } \" " \
'.deployments[0]["packages"]|index("foo") >= 0' \
2017-06-29 17:11:25 +03:00
'.deployments[0]["packages"]|index("bar") >= 0'
upgrader: Use "pending" deployment for origin by default
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: https://github.com/projectatomic/rpm-ostree/issues/406
Closes: #611
Approved by: jlebon
2017-02-08 19:00:18 +03:00
vm_rpmostree uninstall foo
vm_assert_status_jq " .deployments[0][\"base-checksum\"] == \" ${ commit } \" " \
'.deployments[0]["packages"]|index("foo")|not' \
2017-06-29 17:11:25 +03:00
'.deployments[0]["packages"]|index("bar") >= 0'
upgrader: Use "pending" deployment for origin by default
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: https://github.com/projectatomic/rpm-ostree/issues/406
Closes: #611
Approved by: jlebon
2017-02-08 19:00:18 +03:00
echo "ok rollup"