This repository has been archived by the owner on May 7, 2021. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 76
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
This adds a new `run-upgrade` command focused on running upgrade tests. It also adds a single test in that testsuite: `fcos.upgrade.basic`. To run this test, one can do: ``` kola run-upgrade -v \ --cosa-build /path/to/meta.json \ --qemu-image /path/to/starting-image.qcow2 ``` You can tell kola to automatically detect the parent image to start from: ``` kola run-upgrade -v \ --cosa-build /path/to/meta.json \ --find-parent-image ``` For FCOS, this will fetch the metadata for the latest release for the target stream. On AWS, it will use the AMI from there as the starting image. On the QEMU platform, it will download the QEMU image locally (with signature verification). The code is extensible to add support for RHCOS and other target platforms. Why make it a separate command from `run`? Multiple reasons: 1. As shown above, it's about multiple artifacts, not just the system under test. By contrast, `run` is largely about using a single artifact input. For example, on AWS, `--aws-ami` points to the *starting* image, and `--cosa-build` points to the target upgrade. 2. It's more expensive than other tests. To make it truly cross-platform and self-contained, it works by pushing the OSTree content to the node and serving it from there to itself. Therefore, it's not a test that developers would necessarily be interested in running locally very often (though it's definitely adapted for local tests too when needed). 3. Unlike `run`, it has some special semantics like `--find-parent-image` to make it easier to use. Now, this is only part of the FCOS upgrade testing story. Here's roughly how I see this all fit together: 1. The FCOS pipeline runs `kola run-upgrade -p qemu` and possibly `kola run-upgrade -p aws` after the basic `kola run` tests have passed. 2. Once the build is clean and pushed out to S3, its content will be imported into the annex/compose repo. 3. Once there, we can do more realistic tests by targeting the annex repo and a dedicated Cincinnati. For example, we can have canary nodes following those updates that started from various previous releases to catch any state-dependent issues. Another more explicit approach is a test that starts those nodes at the select releases and gate new releases on that test. Essentially, the main advantage of this test is that we can do some upgrade testing *before* pushing out any bits at all to S3. The major bug category this is intended to catch are state-dependent ones (i.e. anything that *isn't* captured by the OSTree commit). However, it does also exercise many of the major parts of the update system (zincati, rpm-ostree, ostree, libcurl). Though it's clearly not a replacement for more realistic e2e tests downstream.
- Loading branch information
Showing
7 changed files
with
456 additions
and
4 deletions.
There are no files selected for viewing
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
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
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
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
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
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
Oops, something went wrong.