## Description
When an EC2 instance boots up with a flatcar image (even the latest) the kubelet fails.
The userdata defines (and should do so) that the `/etc/eks/bootstrap.sh` should run, which it does.
This seems to add a ExecStartPre to the kubelet.service:
`ExecStartPre=/usr/share/oem/eks/download-kubelet.sh`
Both the `bootstrap.sh` and the `download-kubelet.sh` are consistent with:
https://github.com/flatcar-linux/coreos-overlay/blob/main/coreos-base/flatcar-eks/files/bootstrap.shhttps://github.com/flatcar-linux/coreos-overlay/blob/main/coreos-base/flatcar-eks/files/download-kubelet.sh
The `download-kubelet.sh` fails with `Unsupported Kubernetes version` because in the case statement on line 24->50 (https://github.com/flatcar-linux/coreos-overlay/blob/main/coreos-base/flatcar-eks/files/download-kubelet.sh#L25) only has values for kubernetes version 1.15 -> 1.21
If I manually alter the file and add 1.22 (when I test this on 1.22.9 kubernetes version deployment) and re-run the `bootsrap.sh` it works fine as far as I can see, the node than joins the cluster and shows up as `Ready` and pods starting running on the node.
The last PR I can see on this particular thing was done about a year ago f0da7f8c9e
## Impact
No EKS support for kubernetes versions higher than 1.21
## Environment and steps to reproduce
1. **Set-up**: Create an EKS cluster with the latest flatcar AMI in the worker nodes
2. **Task**: SSH into the node (probably through a Bastion)
3. **Action(s)**: No actions needed
4. **Error**: kubelet.service fails because the download-kubelet.sh doesn't have download locations for kubernetes version above 1.21
## Expected behavior
Download locations for kubernetes versions 1.22 and 1.23 (EKS doesn't have support for 1.24 yet it seems) should be located inside the download-kubelet.sh
## Additional information
By running `aws s3 ls s3://amazon-eks/` you can list the available locations of the other versions, so for it should result in this:
``` sh
case $CLUSTER_VERSION in
1.23)
S3_PATH="1.23.9/2022-07-27/"
;;
1.22)
S3_PATH="1.22.12/2022-07-27/"
;;
1.21)
S3_PATH="1.21.2/2021-07-05"
;;
1.20)
S3_PATH="1.20.4/2021-04-12"
;;
1.19)
S3_PATH="1.19.6/2021-01-05"
;;
1.18)
S3_PATH="1.18.9/2020-11-02"
;;
1.17)
S3_PATH="1.17.12/2020-11-02"
;;
1.16)
S3_PATH="1.16.15/2020-11-02"
;;
1.15)
S3_PATH="1.15.12/2020-11-02"
;;
*)
echo "Unsupported Kubernetes version"
exit 1
;;
esac
```
We fetch the latest release of calico from calicoproject/calico
releases instead of from calico-version.yaml file in tigera/operator
repo. This is because we download the Tigera Operator manifest from
the calico repository, so we can expect that when the release happens,
both calico and the operator agree on versions used (so we expect that
calico 3.24.0 is using operator version 1.28.0, and the operator
1.28.0 is using calico 3.24.0).
Update keywords to stable amd64 and arm64.
Note, fix-dos patch is not necessary any more, because 1.3.2-r1 from
upstream Gentoo already has the patch.
Based on commit f3150e4b458e8d8979a37a91e44a7e1d2334d2aa.
and refresh other patches. The changes in PCI irq masking on hyperv resulted in
the previous set of patches not building on arm64. Resolve this by taking
another 2 patches. Patch z0006 makes the non-compiling code x86 specific
(fixing the build failure on arm64) and patch z0007 fixes a subsequent "not
used function" error.
ORIG_HEAD is the previous HEAD, so it is not what we are after. HEAD
only contains the hash if we are in a detached head situation, otherwise
it will contain a ref and we need to resolve it. `git rev-parse HEAD`
should work as well but hits an issue with git's new `safe.directory`
setting, I have not found a way to set this parameter for a signle call.
For toolchain packages are built with catalyst, and the HEAD value needs
to pre-resolved because we do not have access to the whole git
repository. So build_toolchains will need to inject the correct HEAD
file contents.
