[epic] Elemental-toolkit next generation

[davidcassany]

This is a collection of all the tasks required in elemental-toolkit to better align it with upcoming SUSE distributions and other still pending improvements.

• Implement immutable-rootfs module in elemental-cli #1781 (arranged with Elemental boot process #1844)
• Move grub configuration out of state partition #1848
• Create an upgrade test from an old installation to current PR #1928
• Refactor to snapshotter interface (including loopdevices implementation) #1874
• Implement btrfs/snapper snapshotter #1923
• Rethink some of the options for build-disk (probably we should assume all expandable disks are unpriviliged and all full disks are always privileged builds and only support for squashfs recovery for expandable images) #1921
• Rethink upgrade command, probably the --recovery flag should imply an active AND recovery image upgrade (also include bootloader upgrade?). #1922
• Use dracut's default squashfs image paths in ISOs #1865
• Do not include state partition in expandable disks #1925
• Bump elemental-tookit to v2 #1927
• elemental-setup-*.service files have executable bit set #1895

A nice to have:

• Move recovery kernel and initrd out of recovery image #1930
• Refactor cloud-init-paths flag to some hooks specific concept
• Move elemental-setup-* service files to /etc (None of the elemental-setup-*.service files are owned by a package #1896)
• Get rid of all COS references in the code (default labels, paths, etc.)
• Default to squashfs for recovery partition #1864
• Make use of fixed UUIDs for partitions based on Discoverable Partitions Spec
• Support systemd-boot
• scheduled CI for arm64

[bk201]

Get rid of all COS references in the code (default labels, paths, etc.)

Hi David, will this break the current running clusters or there will be an upgrade solution? Harvester nodes are all running with COS_ labels and we still need to support existing customers.

[davidcassany]

@bk201 we are in the process of aligning with the upcoming SUSE distributions, hence it will include relevant refactors of the code and likely to lead us to a v2 version of the toolkit. There are some challenging changes ahead. These are not immediate changes and we already added in high prio setting a proper upgrade test in our CI, so we can detect breaking changes and define proper backward compatibility considerations and constraints.

Regarding the COS_ labels they are configurable and tracked within the state.yaml file. So elemental client reads and applies the labels from there on installed systems. This was already put in place at a time to allow changing default labels without breaking backward compatibility.

[bk201]

@davidcassany Thanks for the explanation.

[kkaempf]

Closing this issue as we've reached 'v2' for toolkit

[bk201]

@davidcassany From #1927, there seem to be some breaking changes. Does this mean we can't upgrade from v1 to v2? And is v1 going to be maintained in the future? Thanks!

[kkaempf]

@bk201 there shouldn't be breaking changes and you should be able to upgrade from v1 to v2.
We might do bug fixes in v1 (none are planned at this time) but actually want everyone to move to v2 in the future.

[bk201]

Thank you for the explanation!