openSUSE:ALP/Workgroups/Installation/DInstaller

Jump to: navigation, search

The ALP Installation work group is researching ways to evolve the current (open)SUSE installer. D-Installer is the provisional codename for the prototype implementing that evolution of YaST.

In a nutshell

D-Installer is an effort to build a web-based installer on top of YaST libraries using Cockpit as a frontend. It requires important architectural changes to YaST, including the development of a D-Bus interface.

Using YaST as a backend has a big advantage - It can easily implement backward compatibility and the code and knowledge already exists. Exchanging components later should be much easier. In that regard, the YaST components of D-Installer will not run as a single monolithic process (like the current YaST), but as a set of pieces running independently and offering their own D-Bus APIs.

Diagram of the architecture of D-Installer

You can find further information in the pages below:

The vision

D-Installer is not so different from YaST in terms of general operation. That is, it's an application that runs on top of a running Linux system (what we usually call the int-sys) and does:

  • some basic network configuration (if needed, that could also be done by the underlying Linux system, whatever it is)
  • configure the storage setup for the target system (partitioning, LVM, encryption...)
  • deploy the target system over that storage setup (via `zypper --root /mnt` or just copying the content of an image),
  • some customizing of the system needed for the first boot (bootloader, kdump, network, etc.) likely by chrooting into the new system,
  • done!

But to be really useful there are several aspects such a installer should fulfill:

  • As mentioned, the installer should be executable from a live system or from some kind of inst-sys similar to the one used by YaST in SLE (hopefully much smaller). It could even be a (set of) container(s) running on top of openSUSE:ALP/Workgroups/Installation/Iguana.
  • Since customers are expected to use their own customized versions of ALP, the installer should support installing different operating systems (vanilla ALP, customer customized images...).
  • It's reasonable to expect similar capabilities to YaST in terms of setting up things that can hardly be configured after the first boot: bootloader, encryption, storage technologies (multipath, LVM, RAID, DASD, iSCSI...), basic network settings, kdump/fadump...
  • The installation process itself should exclude anything that could be reasonably configured by a SCM after/during the first boot.
  • The installer should provide a secure API to drive the installation process and to get feedback about it.
  • For interactive installation, the installer should offer several UIs built on top of the mentioned API. Since every one of those UIs are only one of the possible ways to interact with the mentioned API, it would even be possible in theory to use several UIs in parallel.
  • Those UIs should be more straightforward (with less steps and options) than current versions of YaST.
    • A modern web-based UI could be nice for both local and remote installation.
    • A text-based alternative interface (not necessarily equivalent in functionality to the graphical/web one) would be nice to have for SSH and/or serial installation.
  • The separation between YaST and AutoYaST makes no sense. The difference between interactive or unattended installation should be just a matter of configuration. A configuration parameter could specify whether the installer should wait for the user to change settings and to confirm or whether the installer should just start installing as soon as it can.
  • As a consequence of the above, it should still be possible to connect to an unattended installation using the web or text-based interface at any point of the process to check the progress (or to interrupt it).
  • Unattended installation should work with no dedicated infrastructure at all. Just running the installer with the mentioned configuration parameter to not wait for user interaction would be enough.
  • Talking about configuration, it should be possible to tweak it via the mentioned API, via configuration files (the current difference between the installer control file and the AutoYaST profile makes no sense), via boot params, via environment variables and via [systemd credentials](https://systemd.io/CREDENTIALS/).
  • Thus, not even an AutoYaST profile or SCM should be needed. Just booting via PXE and providing the basic configuration via boot params would suffice. The installer should be able to figure out all the aspects that are not explicitly configured on those boot params.
  • The whole thing should be plugable to SCM (Software Configuration Management) systems and to SUMA (SUSE Manager) with simple and interoperable mechanisms both to be driven and to provide status feedback. See https://trello.com/c/hkR4vv5y/

Unresolved questions with this approach

The vision states that there should be no difference between interactive and unattended installation. But often some kind of logic in needed in that unattended installation. We already see that in AutoYaST, where many users dynamically adjust the process using tools like pre-scripts, ERB templates or rules/class. In all cases, the goal is the same - making configuration dynamic depending on hardware/other conditions. As a very simple example, let's say the user wants to select in unattended installation the second biggest disk (as the biggest is selected by automatic proposal and the user wants to use the other one as the biggest one containing data).

The way to cover those cases is not so clear in the vision expressed above.

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