rpm-ostree/tests/vmcheck/test-layering-relayer.sh

117 lines
3.7 KiB
Bash
Raw Normal View History

#!/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.
set -e
. ${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
vm_build_rpm foo
vm_rpmostree pkg-add foo
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
vm_assert_status_jq \
'.deployments[0]["base-checksum"]' \
'.deployments[0]["pending-base-checksum"]|not'
# let's synthesize an upgrade
commit=$(vm_cmd ostree commit -b vmcheck --tree=ref=vmcheck)
vm_rpmostree upgrade
vm_assert_status_jq \
'.deployments[1]["base-checksum"]' \
'.deployments[1]["pending-base-checksum"]'
vm_rpmostree status --json > status.json
reboot_and_assert_base $commit
vm_assert_status_jq \
'.deployments[0]["base-checksum"]' \
'.deployments[0]["pending-base-checksum"]|not' \
'.deployments[1]["pending-base-checksum"]'
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)
vm_rpmostree deploy my-commit
reboot_and_assert_base $commit
echo "ok deploy"
vm_assert_layered_pkg foo present
echo "ok pkg foo relayered on deploy"
# REBASE
commit=$(vm_cmd ostree commit -b vmcheck_tmp/rebase_test --tree=ref=vmcheck)
vm_rpmostree rebase --skip-purge vmcheck_tmp/rebase_test
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' \
'.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' \
'.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' \
'.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' \
'.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"