Elemental Toolkit vision

[davidcassany]

Within the Elemental team we understand Elemental Toolkit should only provide the essentials to built an Elemental based OS on top of a common Linux OS or distro. According to that principle we aim to rethink and limit the purpose of the elemental-toolkit repository. Elemental-toolkit is becoming unmanageable and hard to maintain and it also suffers from different directions the project took in past. In essence, we believe an Elemental based OS is a rather small collection of utilities and configurations which allows to deploy and maintain the OS from root-tree blobs, commonly OCI images.

Elemental Toolkit core

We believe Elemental Toolkit should encompass the following:

• Elemental client
• The immutable-rootfs
• Bootloader setup
• Cloud init stages setup
• Default or generic cloud init config

Our current implementation relies on grub2 (bootloader), systemd (init system for cloud-init stages and early boot immutable-rootfs stages) and dracut (to create initramfs including immutable-rootfs setup). These are essential tools for most of major and enterprise linux distributions, hence they fit well with the idea of not being tied to any specific distro. Moreover they are not a build requirement and there is none or very little logic exclusively tied to them, we mostly need to configure and use them, hence considering a replacement or alternatives is still perfectly valid and doable.

Decouple Elemental Toolkit from package managers

On the above list only the Elemental client (golang) and the immutable-rootfs (shell script) contain actual code, all the rest are configuration files. We belive we can narrow and reduce the scope of elemental-toolkit repository to provide a pack just including the essentials required to build an Elemental OS on top of a Linux distro. Worth to mention there is no package manager within the list, we understand elemental-toolkit is likely to be distributed as packages, but we see no need to enforce the use of any specific package manager. For that we aim to decouple elemental-toolkit repository from Luet project. Note this is not making Elemental-toolkit incompatible with Luet or incompatible with any other package manager in general, this is about not enforcing the use of any specific package manager implementation.

For that we envision a re structure of the elemental-toolkit repository to something similar to:

toolkit/                 # Folder containing the actual tools and configurations, we could also think of renaiming those subfolders
  immutable-rootfs/
  grub2/
  cloud-init-stages/
  cloud-init-config/
  
examples/                # Few builds based on different distros we could use green for CI tests
  green/
    Dockerfile
  orange/
    Dockerfile
  blue/
    Dockerfile
  
build-recipes/           # A folder that could include build recipes for several package managers
  dockerfile/            # elemental-toolkit could also be provided as container, just as small layer to append on top of a OS root-tree
  specfile/
  debfile/
  luetfile/
  pacmanfile/
  ...
  
README.md
LICENSE
DEVELOPMENT.md

Keep tightly coupled bits together

We also foresee elemental-cli and elemental-toolkit repositories being merged in the future and keep all the coupled bits together, as well as including immutable-rootfs setup and core scripts as commands of elemental-cli. So all the logic could be included within the elemental-cli leaving apart just configurtaion files (systemd units, grub2 configuration, dracut configuration and cloud-init files).

We believe this way can better outline what elemental-toolkit is and what provides and better showcase this is a small and thin layer on top of common widely used Linux distributions. This also makes it possible to easily be consumed by other projects.