🌱 ci: bump Flatcar tested version

[tormath1]

What this PR does / why we need it: Test a new Flatcar major Stable

Special notes for your reviewer: As discussed previously, let's bump Flatcar tested version only for new major. I followed these instructions: https://gist.github.com/tormath1/acbae5c6cd12420bb8ea137e25655c99 (if the tests are green one maintainer could upload the Flatcar image to the CAPO GCS bucket 🙏 , thanks!)

TODOs:

• squashed commits
• if necessary:
  • includes documentation
  • adds unit tests

/hold

[netlify]

✅ Deploy Preview for kubernetes-sigs-cluster-api-openstack ready!

Name	Link
🔨 Latest commit	021a72f
🔍 Latest deploy log	https://app.netlify.com/sites/kubernetes-sigs-cluster-api-openstack/deploys/652555192640b000083456d7
😎 Deploy Preview	https://deploy-preview-1713--kubernetes-sigs-cluster-api-openstack.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[wwentland]

Thank you, looking forward to testing the current stable version.

FWIW, I've used that version in my own clusters already and did not run into issues.

[wwentland]

Is there any way in which we wouldn't have to switch between artifacts.k8s-staging-capi-openstack.appspot.com/test and tormath1-flatcar whenever a new flatcar image is being made available?

I appreciate that an automatic process would be best (cf. #1502), but maybe we can find a different solution in the interim?

[tormath1]

Yes, it's not ideal and it creates bottleneck: one needs to generate the image with the image-builder and one with CAPO GCS Bucket write access needs to upload it.
That said, it's not everyday that a new major Stable is released so I think it's still manageable.
One different approach would be to remove the image-builder dependency and to use plain Flatcar image:

Suggested change

	/opt/stack/devstack/tools/upload_image.sh https://storage.googleapis.com/tormath1-flatcar/flatcar-stable-3602.2.0-kube-v1.27.2.img
	/opt/stack/devstack/tools/upload_image.sh https://stable.release.flatcar-linux.net/amd64-usr/3602.2.0/flatcar_production_openstack_image.img.gz

In the Flatcar template, using Ignition, we could pull Kubernetes dependencies using systemd-sysext: here's a demo with CAPO that I presented during August Flatcar office hours: https://www.youtube.com/live/omppbFNxSDU?si=W74sLp2IH1cL1hCS&t=210

I am planning to write an "experimental" template in the next weeks for folks interested - we discussed about this during a previous CAPO office hours with @mdbooth

[wwentland]

Yes, it's not ideal and it creates bottleneck: one needs to generate the image with the image-builder and one with CAPO GCS Bucket write access needs to upload it.

Indeed, that's exactly what I was wondering we could achieve here: Find a person with the permissions above or grant them.

One different approach would be to remove the image-builder dependency and to use plain Flatcar image: [...] In the Flatcar template, using Ignition, we could pull Kubernetes dependencies using systemd-sysext:

I am very much looking forward to utilising that functionality in all my clusters and, quite likely, in the context of tests here. How far has that feature progressed by now? My impression was that it is still quite experimental. But, if we can make it work, I'd very much like that. Until then, my preference would be for tests to mirror the setup that most users would use.

On that note: Please give me a shout if you need any help in getting the templates ready.

[tormath1]

@wwentland most of the time, a maintainer takes care of the uploading once the CI is green (see: #1524 (comment) for example).

Regarding sysext: as you mentioned, we should continue to test the image produced by the image-builder using the CAPO released template; that's why we could introduce an experimental-flatcar.yaml or equivalent that would consume systemd-sysext images.

Now, regarding the feature itself, it's pretty stable - for example on Flatcar, we started to convert the OEM resources to systemd-sysext images (AWS, OpenStack, etc.): those sysext images are part of the release artifacts now and we continue to collaborate with the upstream to improve the experience.

That would be really helpful to get your feedback on such a template - I'll ping you on the Slack CAPO channel once I'll have something to try. ❤️

[mdbooth]

I still think the ideal situation here is to generate them directly in the CI. Incidentally, the 'OpenStack' packer builder is vastly quicker and more reliable than the qemu builder. The only problem with it is you need an OpenStack to run it against. That's hurting us.

[mdbooth]

@tormath1 I've copied the new image to our storage bucket. I'm happy to merge this once you've bumped the location. Thanks!

/approve

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: mdbooth, tormath1

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [mdbooth]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[wwentland]

That's great, thanks again!

/lgtm

[jichenjc]

/hold cancel
/lgtm

[tormath1]

/retest

[wwentland]

/retest

[wwentland]

I guess that the preferred course of action is to get #1718 merged and to rebase this one? That would ensure that we really only change the Flatcar image here, while CI issues are addressed elsewhere.

[wwentland]

Cheers!

/lgtm