Drop k8s 1.28 and 1.29 metal variants

Signed-off-by: Matthew Yeazel <[email protected]>

Author: yeazelm

Cargo.lock

@@ -31,8 +31,6 @@ members = [
     "variants/aws-k8s-1.30-nvidia",
     "variants/aws-k8s-1.31-nvidia",
     "variants/metal-dev",
-    "variants/metal-k8s-1.28",
-    "variants/metal-k8s-1.29",
     "variants/vmware-dev",
     "variants/vmware-k8s-1.28",
     "variants/vmware-k8s-1.28-fips",

Cargo.toml

@@ -39,7 +39,7 @@ You might need to install `jq` to fetch the VERSION.
 
 ```shell
 ARCH="x86_64"
-VERSION=$(curl -s https://api.github.com/repos/bottlerocket-os/bottlerocket/releases/latest | jq -r '.name')
+VERSION="v1.26.1" # New releases do not have metal-k8s variants
 VARIANT="metal-k8s-1.28"
 IMAGE="bottlerocket-${VARIANT}-${ARCH}-${VERSION}.img.lz4"
 OUTDIR="${VARIANT}-${VERSION}"

PROVISIONING-METAL.md

@@ -92,15 +92,11 @@ We also have variants that are designed to be Kubernetes worker nodes in VMware:
 * `vmware-k8s-1.30`
 * `vmware-k8s-1.31`
 
-The following variants are designed to be Kubernetes worker nodes on bare metal:
-
-* `metal-k8s-1.28`
-* `metal-k8s-1.29`
-
 The following variants are no longer supported:
 
 * All Kubernetes variants using Kubernetes 1.23 and earlier
-* Bare metal and VMware variants using Kubernetes 1.27 and earlier
+* VMware variants using Kubernetes 1.27 and earlier
+* Bare metal variants for Kubernetes
 
 We recommend users replace nodes running these variants with the [latest variant compatible with their cluster](variants/).
 

README.md

@@ -334,59 +334,6 @@ You can monitor the tests with:
 cargo make watch-test
 ```
 
-### metal-k8s
-
-First, an initial baremetal management cluster needs to be created using [`EKS Anywhere`](https://anywhere.eks.amazonaws.com/docs/getting-started/production-environment/baremetal-getstarted/#create-an-initial-cluster).
-You can then set `TESTSYS_MGMT_CLUSTER_KUBECONFIG` to the path to the management clusters kubeconfig.
-You need to [build](BUILDING.md) Bottlerocket and a publicly accessible [TUF repository](https://github.com/bottlerocket-os/bottlerocket/blob/develop/PUBLISHING.md#repo-location) to test metal variants.
-In addition to the management cluster, you will need to [prepare a hardware CSV file](https://anywhere.eks.amazonaws.com/docs/reference/baremetal/bare-preparation/#prepare-hardware-inventory) containing all machines you want to provision and a [cluster config](https://anywhere.eks.amazonaws.com/docs/reference/clusterspec/baremetal/) for the cluster.
-Create a directory in `tests/shared/clusters` with an identifier for this cluster, i.e cluster1 (`tests/shared/clusters/cluster1`).
-In that directory create 2 files, `cluster.yaml` with the EKS Anywhere cluster config, and `hardware.csv`.
-In `Test.toml` set `cluster-names = ["cluster1"]` to tell TestSys that we want the cluster config and hardware csv from the directory we just created.
-
-Metal testing also requires and additional manual step for testing.
-The Bottlerocket build system compresses the metal images with lz4, but EKS Anywhere requires them to be gzipped, so before testing make sure to uncompress the lz4 image and gzip it.
-Make sure it is downloadable from a URL accessible from the management cluster.
-The directory used should be added to `Test.toml` as `os-image-dir`.
-
-Change the commands below to the desired `metal-k8s` variant:
-
-First, build the Metal variant you want to test.
-
-```shell
-cargo make \
-  -e BUILDSYS_VARIANT="metal-k8s-1.29" \
-  -e BUILDSYS_ARCH="x86_64" \
-  build
-```
-
-Build the TUF repo containing the metal images.
-
-```shell
-cargo make \
-  -e BUILDSYS_VARIANT="metal-k8s-1.29" \
-  -e BUILDSYS_ARCH="x86_64" \
-  repo
-```
-
-Make sure you gzip the metal image and add it to your `os-image-dir`.
-
-Now, you can run the test.
-
-```shell
-cargo make \
-  -e BUILDSYS_VARIANT="metal-k8s-1.29" \
-  -e BUILDSYS_ARCH="x86_64" \
-  -e TESTSYS_MGMT_CLUSTER_KUBECONFIG=${TESTSYS_MGMT_CLUSTER_KUBECONFIG}
-  test
-```
-
-You can monitor the tests with:
-
-```shell
-cargo make watch-test
-```
-
 ## Migration Testing
 
 Migration testing is used to ensure Bottlerocket can update from one version to a new version and back.

TESTING.md

@@ -221,19 +221,6 @@ This variant is compatible with Kubernetes 1.31, 1.32, 1.33, and 1.34 clusters.
 The [metal-dev](metal-dev/Cargo.toml) variant has useful packages for local development of the OS and is intended to run bare metal.
 It includes tools for troubleshooting as well as Docker for running containers.
 
-### metal-k8s-1.28: Metal Kubernetes 1.28 node
-
-The [metal-k8s-1.28](metal-k8s-1.28/Cargo.toml) variant includes the packages needed to run a Kubernetes node on bare metal.
-It supports self-hosted clusters.
-
-This variant is compatible with Kubernetes 1.28, 1.29, 1.30, and 1.31 clusters.
-
-### metal-k8s-1.29: Metal Kubernetes 1.28 node
-
-The [metal-k8s-1.29](metal-k8s-1.29/Cargo.toml) variant includes the packages needed to run a Kubernetes node on bare metal.
-It supports self-hosted clusters.
-
-This variant is compatible with Kubernetes 1.29, 1.30, 1.31, and 1.32 clusters.
 
 ### Deprecated variants
 
@@ -446,6 +433,20 @@ It supported self-hosted clusters.
 
 This variant was compatible with Kubernetes 1.27, 1.28, 1.29, and 1.30 clusters.
 
+### metal-k8s-1.28: Metal Kubernetes 1.28 node
+
+The [metal-k8s-1.28](metal-k8s-1.28/Cargo.toml) variant included the packages needed to run a Kubernetes node on bare metal.
+It supports self-hosted clusters.
+
+This variant was compatible with Kubernetes 1.28, 1.29, 1.30, and 1.31 clusters.
+
+### metal-k8s-1.29: Metal Kubernetes 1.29 node
+
+The [metal-k8s-1.29](metal-k8s-1.29/Cargo.toml) variant included the packages needed to run a Kubernetes node on bare metal.
+It supports self-hosted clusters.
+
+This variant was compatible with Kubernetes 1.29, 1.30, 1.31, and 1.32 clusters.
+
 ## Development
 
 Say we want to create `my-variant`, a custom build of Bottlerocket that runs `my-agent`.