docs: update aws-k8s-1.24* references

Signed-off-by: Kush Upadhyay <kushupad@amazon.com>

BUILDING.md

@@ -203,7 +203,7 @@ The specifics of building an out-of-tree module will vary by project, but the fi
 ### Downloading the kmod kit
 
 kmod kits are included in the official Bottlerocket repos starting with Bottlerocket v1.0.6.
-Let's say you want to download the kit for building x86_64 modules for v1.11.0 and variant aws-k8s-1.24.
+Let's say you want to download the kit for building x86_64 modules for v1.31.0 and variant aws-k8s-1.32.
 
 First, you need tuftool:
 ```shell
@@ -220,8 +220,8 @@ sha512sum -c <<<"2ff1fbf99b20dd7ff5d2c84243a8e3b51701183b1f524b7d470a6b7a9b0172f
 Next, set your desired parameters, and download the kmod kit:
 ```shell
 ARCH=x86_64
-VERSION=v1.11.0
-VARIANT=aws-k8s-1.24
+VERSION=v1.31.0
+VARIANT=aws-k8s-1.32
 OUTDIR="${VARIANT}-${VERSION}"
 
 tuftool download "${OUTDIR}" --target-name ${VARIANT}-${ARCH}-kmod-kit-${VERSION}.tar.xz \

PUBLISHING-AWS.md

@@ -91,7 +91,7 @@ This isn't very discoverable yet, but it's useful for testing.
 As an example, a parameter might look like this:
 
 ```
-/your/prefix/here/aws-k8s-1.24/x86_64/1.11.0-b530f30/image_id
+/your/prefix/here/aws-k8s-1.32/x86_64/1.11.0-b530f30/image_id
 ```
 
 Once you're satisfied with your image and parameters, you can promote the parameters to simpler names (for example, "latest") using the [instructions below](#promoting-ssm-parameters).
@@ -133,13 +133,13 @@ cargo make -e SSM_TARGET=latest promote-ssm
 This will copy the fully versioned parameter from earlier, something like:
 
 ```
-/your/prefix/here/aws-k8s-1.24/x86_64/1.11.0-b530f30/image_id
+/your/prefix/here/aws-k8s-1.32/x86_64/1.11.0-b530f30/image_id
 ```
 
 ...to a simpler parameter name:
 
 ```
-/your/prefix/here/aws-k8s-1.24/x86_64/latest/image_id
+/your/prefix/here/aws-k8s-1.32/x86_64/latest/image_id
 ```
 
 You can then use this parameter name to get the latest AMI ID.

PUBLISHING-VMWARE.md

@@ -46,20 +46,20 @@ datacenters = ["foo", "bar"]
 Then you can easily upload your OVA, specifying the variant you wish to upload (currently only VMware variants).
 
 ```shell
-cargo make -e BUILDSYS_VARIANT=vmware-k8s-1.24 upload-ova
+cargo make -e BUILDSYS_VARIANT=vmware-k8s-1.32 upload-ova
 ```
 
 If you would like to upload your OVA as a VM template, you can do this in a single step:
 
 ```shell
-cargo make -e BUILDSYS_VARIANT=vmware-k8s-1.24 vmware-template
+cargo make -e BUILDSYS_VARIANT=vmware-k8s-1.32 vmware-template
 ```
 
 You can override the list of datacenters to upload to by specifying `VMWARE_DATACENTERS`:
 
 ```shell
 cargo make vmware-template \
-  -e BUILDSYS_VARIANT=vmware-k8s-1.24 \
+  -e BUILDSYS_VARIANT=vmware-k8s-1.32 \
   -e VMWARE_DATACENTERS="foo,bar"
 ```
 
@@ -70,6 +70,6 @@ Our [import spec template](tools/pubsys/support/vmware/import_spec.template) can
 
 ```shell
 cargo make vmware-template \
-  -e BUILDSYS_VARIANT=vmware-k8s-1.24 \
+  -e BUILDSYS_VARIANT=vmware-k8s-1.32 \
   -e VMWARE_IMPORT_SPEC_PATH=/path/to/my/spec.toml
 ```

PUBLISHING.md

@@ -215,12 +215,12 @@ These default settings will be applied to your hosts at startup, meaning any hos
 
 The easiest way to change your repo URLs at run time is to include the settings changes in user data.
 This method is covered [in README](README.md#using-user-data).
-For example, if you built the `aws-k8s-1.24` variant for `x86_64` and uploaded to the public S3 bucket `my-bucket`, your URLs could look like:
+For example, if you built the `aws-k8s-1.32` variant for `x86_64` and uploaded to the public S3 bucket `my-bucket`, your URLs could look like:
 
 ```toml
 [settings.updates]
 targets-base-url = "https://my-bucket.s3-us-west-2.amazonaws.com/targets/"
-metadata-base-url = "https://my-bucket.s3-us-west-2.amazonaws.com/aws-k8s-1.24/x86_64/"
+metadata-base-url = "https://my-bucket.s3-us-west-2.amazonaws.com/aws-k8s-1.32/x86_64/"
 ```
 
 ### Waves

QUICKSTART-EKS.md

@@ -95,9 +95,9 @@ If you'd like even more control over your setup, something that eksctl can't (ye
 ### Finding an AMI
 
 The official AMI IDs are stored in [public SSM parameters](https://docs.aws.amazon.com/systems-manager/latest/userguide/parameter-store-public-parameters.html).
-The parameter names look like this: `/aws/service/bottlerocket/aws-k8s-1.24/x86_64/latest/image_id`
+The parameter names look like this: `/aws/service/bottlerocket/aws-k8s-1.32/x86_64/latest/image_id`
 
-Just change the variant (`aws-k8s-1.24`) and architecture (`x86_64`) to the ones you want to use.
+Just change the variant (`aws-k8s-1.32`) and architecture (`x86_64`) to the ones you want to use.
 Supported variants and architectures are described in the [README](README.md#variants).
 For the purposes of SSM parameters, the valid architecture names are `x86_64` and `arm64` (also known as `aarch64`).
 Also, if you know a specific Bottlerocket version you'd like to use, for example `1.11.0`, you can replace `latest` with that version.
@@ -109,23 +109,23 @@ Once you have the parameter name you want to use, the easiest way to use it is t
 (You can also use this method for CloudFormation and other services that launch EC2 instances for you.)
 Just prefix the parameter name with `resolve:ssm:` and EC2 will fetch the current value for you.
 
-For example, to use the parameter above, you would pass this as the AMI ID in your launch request: `resolve:ssm:/aws/service/bottlerocket/aws-k8s-1.24/x86_64/latest/image_id`
+For example, to use the parameter above, you would pass this as the AMI ID in your launch request: `resolve:ssm:/aws/service/bottlerocket/aws-k8s-1.32/x86_64/latest/image_id`
 
 #### Manually querying SSM
 
 If you prefer to fetch the AMI ID yourself, you can use [aws-cli](https://aws.amazon.com/cli/) on the command line.
 To fetch the example parameter above, for the us-west-2 region, you could run this:
 
 ```shell
-aws ssm get-parameter --region us-west-2 --name "/aws/service/bottlerocket/aws-k8s-1.24/x86_64/latest/image_id" --query Parameter.Value --output text
+aws ssm get-parameter --region us-west-2 --name "/aws/service/bottlerocket/aws-k8s-1.32/x86_64/latest/image_id" --query Parameter.Value --output text
 ```
 
 If you have `jq` installed and would like a bit more information, try this:
 
 ```shell
 aws ssm get-parameters --region us-west-2 \
-   --names "/aws/service/bottlerocket/aws-k8s-1.24/x86_64/latest/image_id" \
-           "/aws/service/bottlerocket/aws-k8s-1.24/x86_64/latest/image_version" \
+   --names "/aws/service/bottlerocket/aws-k8s-1.32/x86_64/latest/image_id" \
+           "/aws/service/bottlerocket/aws-k8s-1.32/x86_64/latest/image_version" \
    --output json | jq -r '.Parameters | .[] | "\(.Name): \(.Value) (updated \(.LastModifiedDate | gmtime | strftime("%c")) UTC)"'
 ```
 

QUICKSTART-VMWARE.md

@@ -45,8 +45,8 @@ sha512sum -c <<<"2ff1fbf99b20dd7ff5d2c84243a8e3b51701183b1f524b7d470a6b7a9b0172f
 Next, set your desired version and variant, and download the OVA:
 
 ```shell
-VERSION="v1.6.1"
-VARIANT="vmware-k8s-1.24"
+VERSION="v1.31.0"
+VARIANT="vmware-k8s-1.32"
 OVA="bottlerocket-${VARIANT}-x86_64-${VERSION}.ova"
 OUTDIR="${VARIANT}-${VERSION}"
 

README.md

@@ -57,11 +57,10 @@ We’re excited to get early feedback and to continue working on more use cases!
 Bottlerocket is architected such that different cloud environments and container orchestrators can be supported in the future.
 A build of Bottlerocket that supports different features or integration characteristics is known as a 'variant'.
 The artifacts of a build will include the architecture and variant name.
-For example, an `x86_64` build of the `aws-k8s-1.24` variant will produce an image named `bottlerocket-aws-k8s-1.24-x86_64-<version>-<commit>.img`.
+For example, an `x86_64` build of the `aws-k8s-1.32` variant will produce an image named `bottlerocket-aws-k8s-1.32-x86_64-<version>-<commit>.img`.
 
 The following variants support EKS, as described above:
 
-* `aws-k8s-1.24`
 * `aws-k8s-1.25`
 * `aws-k8s-1.26`
 * `aws-k8s-1.27`
@@ -70,7 +69,6 @@ The following variants support EKS, as described above:
 * `aws-k8s-1.30`
 * `aws-k8s-1.31`
 * `aws-k8s-1.32`
-* `aws-k8s-1.24-nvidia`
 * `aws-k8s-1.25-nvidia`
 * `aws-k8s-1.26-nvidia`
 * `aws-k8s-1.27-nvidia`
@@ -97,7 +95,7 @@ We also have variants that are designed to be Kubernetes worker nodes in VMware:
 
 The following variants are no longer supported:
 
-* All Kubernetes variants using Kubernetes 1.23 and earlier
+* All Kubernetes variants using Kubernetes 1.24 and earlier
 * VMware variants using Kubernetes 1.27 and earlier
 * Bare metal variants for Kubernetes
 

TESTING.md

@@ -187,18 +187,18 @@ You will need to delete the EKS cluster manually when you are done using it.
 
 ```shell
 cargo make \
-  -e BUILDSYS_VARIANT="aws-k8s-1.24" \
+  -e BUILDSYS_VARIANT="aws-k8s-1.32" \
   -e BUILDSYS_ARCH="x86_64" \
   build
 
 cargo make \
-  -e BUILDSYS_VARIANT="aws-k8s-1.24" \
+  -e BUILDSYS_VARIANT="aws-k8s-1.32" \
   -e BUILDSYS_ARCH="x86_64" \
   -e PUBLISH_REGIONS="us-west-2" \
   ami
 
 cargo make \
-  -e BUILDSYS_VARIANT="aws-k8s-1.24" \
+  -e BUILDSYS_VARIANT="aws-k8s-1.32" \
   -e BUILDSYS_ARCH="x86_64" \
   test
 ```