Skip to content
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

testsys: aws-k8s migration testing with cargo make test #2273

Merged
merged 1 commit into from Aug 12, 2022

Conversation

ecpullen
Copy link
Contributor

Issue number:
#2149

Description of changes:
Introduces migrations to cargo make test. The added documentation in TESTING.md will help any user set up the necessary infrastructure to run migration testing with all aws-k8s variants.

Testing done:
Used cargo make -e TESTSYS_TEST=migration test to run a migration test on aws-k8s-1.21 and all tests passed successfully.

Terms of contribution:

By submitting this pull request, I agree that this contribution is dual-licensed under the terms of both the Apache License, version 2.0, and the MIT license.

@ecpullen ecpullen changed the title Cargo make updown aws-k8s migration testing with cargo make test Jul 14, 2022
@ecpullen ecpullen changed the title aws-k8s migration testing with cargo make test testsys: aws-k8s migration testing with cargo make test Jul 14, 2022
Makefile.toml Outdated Show resolved Hide resolved
Makefile.toml Outdated Show resolved Hide resolved
TESTING.md Outdated Show resolved Hide resolved
TESTING.md Outdated Show resolved Hide resolved
TESTING.md Outdated Show resolved Hide resolved
tools/Cargo.lock Outdated Show resolved Hide resolved
@ecpullen
Copy link
Contributor Author

^ addressed @jpculp comments

migrate_to_version: self
.migrate_to_version
.as_ref()
.context("You must provide a target version for upgrade downgrade testing.")?
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A little late to comment on this, but I just realized that in all the Bottlerocket repo, we don't use anyhow and instead we use snafu. I think we should be consistent and move at least this part of testsys to snafu. I'm not blocking on this though but an issue should be good.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I will add an issue for this.

tools/testsys/src/aws_resources.rs Show resolved Hide resolved
tools/testsys/src/aws_resources.rs Show resolved Hide resolved
Comment on lines 338 to 339
/// An enum to differentiate between upgrade and downgrade tests. `MigrationVersion::Starting` will
/// create a migration to the starting version.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: comments related to each enum should be on top of the enum.

Comment on lines 383 to 384
MigrationVersion::Starting => migration.starting_version.to_string(),
MigrationVersion::Migrated => migration.migrate_to_version.to_string(),
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

starting_version and migrate_to_version are both String, why the need of to_string()?

tools/testsys/src/aws_resources.rs Show resolved Hide resolved
tools/testsys/src/aws_resources.rs Outdated Show resolved Hide resolved
Makefile.toml Show resolved Hide resolved
TESTING.md Show resolved Hide resolved
@ecpullen
Copy link
Contributor Author

^ addresses @arnaldo2792 comments

TESTING.md Outdated
In order to accomplish this a few artifacts need to be created:
* `TUF` repos that are publicly accessible
* A previous release of bottlerocket signed with available keys
* The ami id from the previous release
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: sed 's/ami/AMI'

TESTING.md Outdated
Migration testing starts testsys at a starting version, or a provided initial image id and migrates instances to the target version.
In order to accomplish this a few artifacts need to be created:
* `TUF` repos that are publicly accessible
* A previous release of bottlerocket signed with available keys
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: sed 's/bottlerocket/Bottlerocket'

TESTING.md Outdated
* `TUF` repos that are publicly accessible
* A previous release of bottlerocket signed with available keys
* The ami id from the previous release
* Build images and repos for current changes
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: a link to the documentation that explains how to build and publish repos would be nice

TESTING.md Outdated

#### Prepare `Infra.toml`

A publicly available s3 bucket is needed to complete the next steps, once a bucket is created the steps may be continued.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is not true, a contributor can use whatever they want to store their TUF repositories, so it will be best to say "the URL of a TUF repository" or something along those lines.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The example steps I provide include syncing tuf repos with the pre-update metadata. I was trying to make the process of onboarding to testsys as easy as possible by providing a sample workflow from start to finish. I can add to the beginning that it is not required to have, but this example will use it.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it will be best to point whomever reads this guide to this document so that they are aware that they are free to decide where to store their TUF repo. I would definitely remove the "publicly" available part since that isn't a good practice, and we shouldn't advocate for that. It will be best to say "use the URL of an accessible TUF repo"; and for your example, assume the contributor followed the link you will add, and that they have a URL that is on top of a properly configured S3 bucket (that's what ultimately happened in the document I linked).

TESTING.md Outdated
#### Prepare `Infra.toml`

A publicly available s3 bucket is needed to complete the next steps, once a bucket is created the steps may be continued.
`Infra.toml` is used by testsys to determine tuf repo locations, so `metadata_base_url` and `targets_base_url` need to be set based on the s3 bucket. The examples below assume `metadata_base_url` is the top level directory of the bucket and `targets_base_url` is a directory named `targets` in the top level directory.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: a line per sentence

TESTING.md Outdated
#### Starting bottlerocket images

In this example we will use `v1.8.0` as our starting bottlerocket version, but any tag from bottlerocket will work.
The following bash will checkout the proper branch from git and create the build images and repos for testing.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
The following bash will checkout the proper branch from git and create the build images and repos for testing.
The following bash script will checkout the proper branch from git and create the build images and TUF repos for testing.

TESTING.md Outdated

```shell
export TESTSYS_STARTING_VERSION="1.8.0"
git checkout v${TESTSYS_STARTING_VERSION}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
git checkout v${TESTSYS_STARTING_VERSION}
git checkout "v${TESTSYS_STARTING_VERSION}"

TESTING.md Outdated
cargo make repo
```

Next, the repos need to be added to the `TUF` repos (s3 bucket). Make sure to change `S3_BUCKET_NAME` to the `TUF` repo bucket name.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think all mentions of a S3 bucket should be removed, folks in the community may have their own way to update their TUF repos.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See above comment. Should we remove the step by step guide so that we can remove the s3 bucket bits?

TESTING.md Outdated

```shell
WORKING_BRANCH="develop"
git checkout ${WORKING_BRANCH}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit:

Suggested change
git checkout ${WORKING_BRANCH}
git checkout "${WORKING_BRANCH}"

TESTING.md Outdated
git checkout ${WORKING_BRANCH}
```

Now, [Release.toml](Release.toml) may need to be updated.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For this testing it must, right?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For using develop yes. But if someone wanted to try building 1.6.0 and 1.6.1 to see how testsys migrations work they wouldn't need to.

Makefile.toml Outdated Show resolved Hide resolved
TESTING.md Outdated Show resolved Hide resolved
TESTING.md Outdated Show resolved Hide resolved
TESTING.md Show resolved Hide resolved
TESTING.md Outdated Show resolved Hide resolved
TESTING.md Outdated Show resolved Hide resolved
TESTING.md Outdated Show resolved Hide resolved
tools/testsys/Cargo.toml Outdated Show resolved Hide resolved
TESTING.md Outdated Show resolved Hide resolved
TESTING.md Outdated Show resolved Hide resolved
@ecpullen ecpullen force-pushed the cargo-make-updown branch 2 times, most recently from d512ebc to 0463854 Compare July 27, 2022 21:44
@ecpullen
Copy link
Contributor Author

^^ Address @etungsten comments
^ rebase to develop

@ecpullen ecpullen requested a review from etungsten July 27, 2022 21:47
Makefile.toml Outdated Show resolved Hide resolved
TESTING.md Outdated Show resolved Hide resolved
TESTING.md Outdated Show resolved Hide resolved
TESTING.md Outdated Show resolved Hide resolved
TESTING.md Outdated Show resolved Hide resolved
@ecpullen
Copy link
Contributor Author

ecpullen commented Aug 2, 2022

^ spell check on markdown and automatically determine correct AMI ID using previous bottlerocket release tag.

TESTING.md Outdated
Comment on lines 210 to 217
The last step with the older Bottlerocket version is retrieving the AMI that was created.

```shell
BUILDSYS_ARCH="x86_64"
BUILDSYS_VARIANT="aws-k8s-1.21"
REGION="us-west-2"

AMIS_JSON="build/images/${BUILDSYS_ARCH}-${BUILDSYS_VARIANT}/latest/bottlerocket-${BUILDSYS_VARIANT}-${BUILDSYS_ARCH}-amis.json"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this step still needed for something?

TESTING.md Outdated
cargo make repo
```

Next, the local repos need to be added to the TUF repos.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Next, the local repos need to be added to the TUF repos.
Remember to sync your TUF repos with the new metadata and targets.

Comment on lines 69 to 71
/// Creates 5 `Test` crds for migration testing. Consisting of a `quick` test, a migration to
/// the target version, a `quick` test to validate the migration, a migration to the starting
/// version, and a `quick` test to validate the second migration.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: this sort of comment seems like it could get outdated pretty quickly - it's specific in both the number and order of the tests.

It might be better to document each of the steps inline, since there's a natural separation after each depends_on.push() to talk about what & why each CRD is added.

let initial = self.sonobuoy_crd("-1-initial", SonobuoyMode::Quick, None, testsys_images)?;
depends_on.push(initial.name().context("Crd missing name")?);
let start_migrate = self.migration_crd(
format!("{}-2-migrate", self.cluster_name()),
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not a big deal here but I wonder if we could do the numbering somewhere else, so it's automatically part of the name in the output based on the position in the vector.

Some(depends_on.clone()),
testsys_images,
)?;
depends_on.push(start_migrate.name().context("Crd missing name")?);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also not a big deal here but should "name" be a required field or have a default value?

I wonder if the cases where the name is optional are worth the added friction in what feels like the normal case here. You could potentially have a NamedCrd type and add a From impl to Crd for it.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The crd itself (for tests and resources) has the name field as an Option so somewhere there needs to be an unwrap() or context() to read it unless we default with "", but that has the potential to cause issues if the field was missing for some reason.

Comment on lines +371 to +376
/// Return the name of the instance provider that the migration agents should use to get the
/// instance ids.
fn instance_provider(&self) -> String;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This seems like a place where stronger typing could be useful. It sort of sticks out as having not very much to do with migration testing.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was wondering if an instance provider trait would be helpful or not.

tools/testsys/src/aws_resources.rs Outdated Show resolved Hide resolved
tools/testsys/src/run.rs Outdated Show resolved Hide resolved
tools/testsys/src/run.rs Outdated Show resolved Hide resolved
tools/testsys/src/run.rs Outdated Show resolved Hide resolved
@ecpullen ecpullen merged commit cc1e7fe into bottlerocket-os:develop Aug 12, 2022
@ecpullen ecpullen deleted the cargo-make-updown branch August 12, 2022 22:19
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants