AL2022 AMI name - drop root volume type, add kernel version

[yinyic]

Summary

Drop root volume type and add kernel version to AL2022 ECS Optimized AMI names, in order to be more consistent with AL2022 AMI naming.

Implementation details

• Added new vars kernel_version_al2022 and kernel_version_al2022arm. The variables will be populated when running generate-release-vars.sh, if the kernel versions are present in base AL2022 AMI names.
• Updated individual AL2022 AMI recipes to drop the -ebs root volume type, as well as pick up kernel version parameter.

Testing

• New tests cover the changes: no
• Verified with local AMI builds that the new AMI names now have kernel version, and no longer have volume types

% ./generate-release-vars.sh 1.64.0-1 20221008

% cat release.auto.pkrvars.hcl | grep kernel
source_ami_al2022    = "al2022-ami-minimal-2022.0.20220928.0-kernel-5.15-x86_64"
source_ami_al2022arm = "al2022-ami-minimal-2022.0.20220928.0-kernel-5.15-arm64"
kernel_version_al2022    = "-kernel-5.15"
kernel_version_al2022arm = "-kernel-5.15"

% REGION=us-west-2 make al2022
...
==> amazon-ebs.al2022: Prevalidating AMI Name: unofficial-amzn2022-ami-ecs-hvm-2022.0.20221008-kernel-5.15-x86_64


% REGION=us-west-2 make al2022neu
...
==> amazon-ebs.al2022neu: Prevalidating AMI Name: unofficial-amzn2022-ami-ecs-neuron-hvm-2022.0.20221008-kernel-5.15-x86_64


% REGION=us-west-2 make al2022arm
...
==> amazon-ebs.al2022arm: Prevalidating AMI Name: unofficial-amzn2022-ami-ecs-hvm-2022.0.20221008-kernel-5.15-arm64

• Verified that when kernel version is missing from base AL2022 AMI we will also omit it in ECS AMI names

% ami_name_al2022_x86="al2022-ami-minimal-2022.0.20220928.0-x86_64"  
% kernel_version_al2022=$(grep -o -e "-kernel-[1-9.]*" <<< "$ami_name_al2022_x86")
% ami_name_al2022="unofficial-amzn2022-ami-ecs-hvm-2022.0.20221008${kernel_version_al2022}-x86_64"
% echo $ami_name_al2022
unofficial-amzn2022-ami-ecs-hvm-2022.0.20221008-x86_64

Description for the changelog

AL2022 AMI name - drop root volume type, add kernel version

Licensing

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

[yinyic]

I had to set them even though they are technically not used in the past release, because otherwise packer static-check throws

Error: Unset variable "kernel_version_al2022"
A used variable must be set or have a default value

[chienhanlin]

I just found that there are new names for us to get AL2022 and AL2022 ARM AMI IDs with the specified kernel version in SSM. Can we update the script to use the new name as we will prefer to support AMIs with certain kernel version and release AMIs with new kernel version after testing is done?

New name field for SSM:

• AL2022: /aws/service/ami-amazon-linux-latest/al2022-ami-minimal-kernel-5.15-x86_64
  ami-0a100548f6e970961 in us-west-2
  ^ the same AMI ID as using "/aws/service/ami-amazon-linux-latest/al2022-ami-minimal-kernel-default-x86_64" returned so far
• AL2022 ARM: /aws/service/ami-amazon-linux-latest/al2022-ami-minimal-kernel-5.15-arm64
  ami-0a11fe2d14d48cb2d in us-west-2
  ^ the same AMI ID as using "/aws/service/ami-amazon-linux-latest/al2022-ami-minimal-kernel-default-arm64" returned so far

[yinyic]

we will prefer to support AMIs with certain kernel version and release AMIs with new kernel version after testing is done

I think, ideally, ECS AMIs want to stay in sync with AL on the "recommended" (or default) kernel version. It does mean that we need to work with AL on qualification, before they start pointing the default image to the ones with newer kernels.

But either way, I'd prefer to take it as a separate issue, which can have a more profound change (changing source AMIs) than what this PR is intended for (just updating ECS AMI names).

[chienhanlin]

Should we merge kernel_version_al2022 and kernel_version_al2022arm into one variable kernel_version_al2022 when we update the generate-release-vars.sh to use the kernel version and get AL2022 and AL2022 ARM AMI IDs from SSM? If it is yes, should we set default value kernel-5.15 for kernel_version_al2022 in variables.pkr.hcl instead of adding new variables to the generate-release-vars.sh?

[yinyic]

Same comment as above - would like to have a separate discussion on whether we would like to start pinning kernel versions for ECS Optimized AMIs.