[RFE] STACKIT support

[robinschneider]

Current situation

There is no Flatcar image for STACKIT.

Impact

There is no easy way for customers to use Flatcar on STACKIT.

Ideal future situation

Easy to use flatcar image for STACKIT.

Implementation options

• [x] Ignition support (provided by OpenStack)
• [x] Afterburn support (provided by OpenStack)
• [ ] Flatcar OEM support
• [ ] Documentation
• [ ] Mantle test suite support
• [ ] ci-automation

Additional information

Currently, it is possible to use Flatcar with the packer OpenStack extension, Flatcar is used for the STACKIT Kubernetes Engine, now we want to create our own OEM image with custom changes such as additional packages and config.

[tormath1]

Hi @robinschneider,

Currently, it is possible to use Flatcar with the packer OpenStack extension

What is the "packer OpenStack extension"? Does it mean that STACKIT runs on OpenStack? If yes, we could simple keep the OpenStack image format but provides an oem-stackit extension with your specific software in it? (Similar to Brightbox)

[robinschneider]

Hi @robinschneider,

Currently, it is possible to use Flatcar with the packer OpenStack extension

What is the "packer OpenStack extension"? Does it mean that STACKIT runs on OpenStack? If yes, we could simple keep the OpenStack image format but provides an oem-stackit extension with your specific software in it? (Similar to Brightbox)

Yes, STACKIT runs on OpenStack. For now we want to add net-misc/chrony as well as a config for chrony to the image. What is needed for an oem-stackit extension? I could not find any oem-extension inside the sysext-bakery repository.

[ader1990]

Hello @robinschneider, one example would be these two PRs on how to add a new oem-stackit extension: https://github.com/flatcar/scripts/pull/1806. The difference would be that you ll need to add the net-misc/chrony similar to this change https://github.com/flatcar/scripts/pull/2309/files#diff-6be6ef0f28bce7244ee46c0c99d921f3e9f46d34f7d0f7912d6fc87226a49e61R20 and also add the net-misc/chrony to the packages-stable. Update: actually, net-misc/chrony is already present here: https://github.com/flatcar/scripts/tree/main/sdk_container/src/third_party/portage-stable/net-misc/chrony

Would be nice also to have such steps documented in the official docs - Adding a new oem-<provider> extension maybe?

[robinschneider]

Hello @robinschneider, one example would be these two PRs on how to add a new oem-stackit extension: flatcar/scripts#1806. The difference would be that you ll need to add the net-misc/chrony similar to this change https://github.com/flatcar/scripts/pull/2309/files#diff-6be6ef0f28bce7244ee46c0c99d921f3e9f46d34f7d0f7912d6fc87226a49e61R20 and also add the net-misc/chrony to the packages-stable. Update: actually, net-misc/chrony is already present here: https://github.com/flatcar/scripts/tree/main/sdk_container/src/third_party/portage-stable/net-misc/chrony

Would be nice also to have such steps documented in the official docs - Adding a new oem-<provider> extension maybe?

First of all thanks for the reply!

I didn't fully understand it: At what point does this extension differ from a 'full image'? How does the OpenStack image need to be referenced in order to reuse the image format? What am I missing here?

Adding some docs on how to add an oem-<provider> this as well should not be the issue once I achieved it :)

[tormath1]

In Flatcar there is what we call the "generic image": it is the base image used by all providers / all platforms. On top of this image, we add the oem-<provider> sysext image which holds the specifics for the cloud provider (e.g files, packages, configuration, etc.).

This OEM sysext image^1 is not built with the sysext-bakery because they are part of the official image and are added during the build. If you SSH into an OpenStack image, you'll find an oem-openstack sysext, if you SSH into an Azure image you'll find oem-azure sysext, etc.

If I understand correctly, you are happy with the OpenStack image now but you would like to have an oem-stackit sysext with some software (chrony) and configuration in it. This means that you will continue to use Ignition for OpenStack, Afterburn for OpenStack etc.

If this is correct, then I think the implementation would be straightforward:

1. Adds a new oem-stackit - I think the oem-vmware is a good example as it has a dependency to another package.
2. In this file, build_library/vm_image_util.sh, we could add this:

## stackit
IMG_stackit_DISK_FORMAT=qcow2
IMG_stackit_DISK_LAYOUT=vm
IMG_stackit_OEM_PACKAGE=common-oem-files
IMG_stackit_OEM_USE=openstack
IMG_stackit_OEM_SYSEXT=oem-stackit

This should produce a stackit image based on OpenStack using the oem-stackit sysext image. (note: we might need to extend IMG_stackit_OEM_SYSEXT to support a list of OEM and not a single one. Here's it's not an issue because the OpenStack OEM does nothing)

[t-lo]

This should produce a stackit image based on OpenStack using the oem-stackit sysext image. (note: we might need to extend IMG_stackit_OEM_SYSEXT to support a list of OEM and not a single one. Here's it's not an issue because the OpenStack OEM does nothing)

I'd rather solve this at the ebuild level and would have oem-stackit depend on oem-openstack (if there were such a thing). Sysexts don't have dependency management, ebuilds do.

This is purely theoretical of course since as you stated OpenStack doesn't need OEM tools.

[tormath1]

I'd rather solve this at the ebuild level and would have oem-stackit depend on oem-openstack (if there were such a thing). Sysexts don't have dependency management, ebuilds do.

Ah yes, did not think about it. 👌

[robinschneider]

So far I am not sure what I am missing, but when I create an image, I get an oem-stackit image and I can upload it to OpenStack and create a cluster using this image, but crony does not work. There is no chrony running on these flatcar machines then. I created a draft PR https://github.com/flatcar/scripts/pull/3018, any feedback on what is wrong/missing is highly appreciated.

[tormath1]

Support has been merged to Alpha, Beta and Stable and should be available at next Flatcar releases. In the meantime, nightly builds will be available for testing.

Next step is documentation.

[tormath1]

Documentation is now done: https://github.com/flatcar/flatcar-website/pull/456 - next step would be test implementation and CI automation. :)