This wiki was updated to MediaWiki 1.37. If you notice any issues, please report them to admin[at]opensuse.org

openSUSE:ALP/Workgroups/Installation/Context

Jump to: navigation, search

A full-feature installer as previously available on SLE 15 or openSUSE Leap is not expected in ALP. The first task for this work group is to find out who are the stakeholders and what are the minimal set of expectations and requirements.

The goal is to deploy the Host OS and leave the rest of the system configuration to the configuration management. This deployment should support image deployment (and use results from Image-based Installation and Update work group) with an option to add additional RPMs (hardware driver for disk or network).

This work group is closely related to the Full-disk encryption work group and its results too.

This installer/deployer in bare-metal (or similarly VMs) should support interactive installation and also be useful to unattended deployments.

It should as well support local installation (with a screen, keyboard, etc.) and remote one (ssh, web or some similar technology).

Some Requisites

As a first attempt to clarify the scope of the work group, a set of open questions was collected. Some of them were answered in a meeting with the ALP Steering Committee. Check this etherpad with the questions and the answers.

Summarizing those answers:

  • It's quite expected that ALP users will generate their own customized images, so the ability to install several images could be quite important.
  • The installer should be able to create or reuse the required partition for booting. For example, /boot/efi in x86, /boot/zipl in s390, PReP in ppc, etc.
  • The installer should cover complex custom storage/booting/network scenarios like, for example, systems with full network-based storage or installing a system spread over several devices including stuff like RAID or multidevice Btrfs.
  • It's not clear how licensing should be controlled in the case of SLE. So there are not clear requisites in terms of the registration process. But there is a Telemetry work-group that is somehow taking care of that.
  • The installer should provide an unattended mode. If possible well integrated with SUMA, Ansible and Salt.
  • No AutoYaST backwards compatibility is expected.
  • The installer is not expected to be used in environments with very little memory like virtual machines or edge. In those cases just dropping an image would be the expected mechanism to get ALP into the system.

Things to configure during installation

If we want ALP to be an alternative for the well-established users of SLE and Leap, the deployment of ALP on bare-metal should take the following aspects/technologies into account:

  • Storage management (many current SLE & Leap users install the operating system on top of a combination of all this):
    • Types of devices:
      • Local devices (hard disks, NVMe, removable devices, etc.)
      • DASDs - IBM s/390 mainframe (virtual) disks that needs previous activation process
      • Network storage (configuration needed):
        • iSCSI including support for iBFT
        • FCoE (and zFCP)
        • NVMe oF/TCP including support for the upcoming NBFT
        • NFS
    • Storage organization:
      • Partitions (including several partition table types like GPT, MSDOS or DASD).
      • LVM (including snapshots, thin provisioning, etc.)
      • Btrfs capabilities (snapshots, subvolumes, multi-volume, RAID...)
      • Multipath
      • RAID (software RAID, pure firmware RAID and some intermediate solutions)
      • Tmpfs
      • Encryption (LUKS, TPM2, IBM's pervasive encryption...)
      • Caching (bcache)
  • Bootloader configuration (partially related to storage)
    • Including hibernation
  • Network configuration:
    • Systems to configure:
      • System during installation (a.k.a. int-sys) - may be needed to control the process (via web, ssh, SCM) or to access some resources
      • Deployed system - often, but not always, just replicating the configuration of the inst-sys
    • Types of network/technologies that should be configurable during installation
      • Wired
      • Wireless
    • Proxy configuration for accessing images / repositories
    • Basic firewall settings for remote management (or keeping defaults)
  • Kdump configuration
  • NTP configuration (for secure connections to work properly), see NTP in the installer - comparison
  • Administrator's password / keys / ... (for managing the system later)