Current situation

The Azure OEM partition holds a custom Python distribution for waagent and a base Ignition definition to create a systemd service.
The custom Python causes problems because of the non-standard location and missing parts of the library.

Impact

Some Azure extensions won't run with the custom Python distribution and we also don't have an update mechanism for the OEM partition and the files created on the rootfs by Ignition.

Ideal future situation

We now want to migrate to using a systemd-sysext image stored as file on the OEM partition and updated by update-engine.
A benefit of sysext images is that they can have a strict coupling to the Flatcar VERSION_ID which enables to use dynamical linking to save space and make the OEM tool packages simpler. We can build the regular python and use a standard location.
The base Ignition configuration is not needed anymore because the sysext's OEM files already become part of the /usr hierarchy and systemd services there may be enabled through shipped symlinks.

Implementation options

Done: The installation of ebuild files into the sysext image could be done by installing to a directory and then using squashfs (Packages installed in the /usr partition must not be installed again).

Additional information

Done: For testing one needs the helper service from #768 that sets up the symlink for the active sysext image.

Tasks

To quickly get first results and ship the work, the new idea now is to postpone the update support.
The following tasks are worked on or need to be worked on for this MVP:

• Move OEM mount point out of /usr #766 → PRs are prepared, testing needed as this touches many places, maybe this can be merged before the Azure OEM sysext migration @krnowak
• export portage db, oem sysext utils, sysext for azure scripts#858 → We need to change the Azure OEM sysext PR to use SYSEXT_LEVEL instead of VERSION_ID for the mean time, maybe don't create the active-oem-${OEMID} flag file (see below) @krnowak
• … and of course, testing and debugging needed for the above PR
• Find a way in bootengine to accommodate this special case of a sysext image that is not updated: Maybe we can define a magic version like initial and when this sysext image exists, the symlink gets created but we don't enter the full A/B logic by not creating the active-oem-${OEMID} flag file during image build: @pothos setup-root: Detect initial sysext MVP bootengine#62