openSUSE:ALP/Workgroups/Installation/Iguana

Jump to: navigation, search

The ALP Installation work group wants to give a try to a new concept of installation. Iguana is the provisional codename for the prototype implementing that concept.

In a nutshell

The installer will build an ALP image fully customized to match the system and will then deploy such an image.

Iguana's base is a small initrd that can execute containers. Then the installer itself is made of several components, all running as containers. Some of those components will be in charge of generating the image, using the same tools that are used for generating the "canonical" ALP images.

Main high-level steps:

  • Analysis of the system and reading of user settings
  • Generation of a manifest based on the previous step
  • That manifest is used to generate a fully customized image
  • The image is deployed

Repository

https://github.com/aaannz/dracut-iguana

The vision

Given the vast scope what we want to cover with ALP, reading other work group ideas and what we talked about in meetings we all agree that the installer itself will continue to be one and must continue to be just one of many different kinds of initrds/boot images provided to users within ALP ecosystem. We are not trying to be on each and every ALP image.

We position "installer boot image" as the one capable of dealing with both packages and images. Need for packages was established because of 3rd party software needs. Need for images because I am assuming that ALP will distribute some of its parts as complete OCI images and maybe even other different types of images (e.g. flatpak, sys-ext systemd images).

Installer boot image is able to perform

  • attended local and remote installations (for users with "normal" HW, no ipmi, etc and without extra installation server aka "how would I install it at home?")
  • unattended installations based on some kind of manifest

Installer should work with some reasonable hardware out of the box. For some exotic HW configurations, there needs to be a mechanism how drivers and/or metadata (e.g. custom mandatory partitioning) can be appended to installer. I believe that this mechanism should not touch installer boot image itself, rather be an extension to it loaded e.g. by using overlayfs. Another open question is how to validate this extension if we enable users to build their own.

Installation should be done with the very same tools that ALP images are build, with the exception it is not build into some output file, but directly onto the storage media. Using these tools, installer would support everything what we would support when building images (e.g. configuration of services, users, etc.). This will also ideally allow some debugging help as with users installation manifest we should be able to build the same image and work with it.

Installers job thus will be to gather data from HW, user (in case of attended installation) and if provided some kind of manifest and create "installation manifest" from which it will build/install the machine using well known tooling.

This installation manifest should be made available for debugging purposes and should be the same what is used for building other official ALP images.

The scope of that data we gather from user is thus dependent on how much such build system can configure (and UX design, of course).

Dynamic stuff as described [this section] would be the same users would use if they would build their own image using ALP tooling.

An important advantage of this approach of combining a small initrd that is always the same with a set of containers is that the initrd and the containers could all be signed, ensuring the integrity of the overall set of components.

Unresolved questions with this approach

  • We do not know what the image building tooling will look like at this point.
  • We do not know how the images produced by this tooling will look like, but I tend to assume they will be at most filesystem images, e.g. one partition, as this all exercise is to make ALP more container friendly. I do not think they will be what we currently know as OEM images, whole disk images.
  • Since we do not know the tooling, we don't know how much effort it will be to modify it to build on real storage rather then to some file.

Notes about interoperability with SUMA (SUSE Manager)

Currently, in SLE15 world, SUMA either uses autoyast or saltboot to install/deploy systems. As established in the beginning, installer will be just one of the available boot images. For SUMA saltboot we will have separate boot image with salt included where it will be it's responsibility to adhere to APL standards and does not use installer at all.

For manifest based installation we do not know yet how this will look like, but looking back into SLE15 world we add autoyast post install scripts which correctly configures pre installed salt-minion. End goal is that once machine boots to system it will be shown on SUMA automatically. If installer will have some boot image extensions, we may very well have some SUMA specific boot image extension providing all the necessary configurations.

Retrieved from "https://en.opensuse.org/index.php?title=openSUSE:ALP/Workgroups/Installation/Iguana&oldid=168229"