Comparison of Installation routine between Kubic and SUSE CaaS Platform v3 (Jun 2018)

This article serves as overview documentation of the Kubic and CaaSP v3 installation routines and analysis of the differences. It will also identify any deficiencies in the current Kubic routine that needs to be resolved before it can be considered as a total replacement for SUSE CaaS Platform v4

CaaSP v3 Installation Overview

CaaSP uses an installation workflow which focuses on the yast2-caasp module.

Installation starts, running through the usual analysis modules. The first interactive window is the Beta warning (if applicable)

https://openqa.suse.de/tests/1750397#step/oci_overview/1

Assuming the user accepts the Beta warning, they are presented with the yast2-caasp one screen installer module

https://openqa.suse.de/tests/1750397#step/oci_overview/2

From here users can select

Language
Keyboard Layout
Password for Root User
Registration Code/SMT Server URL
Partitioning
Boot Loader Config
Network Config
KDump Config
System Role

License is shown just before installation as part of the final confirmation step

System Role Selection

If the user selects Admin Node, the yast2-caasp one screen installer displays an "NTP Servers" field, requiring the user to enter the NTP servers needed

If the user selects Worker Node, the yast2-caasp one screen installer displays an "Administration Node" field, requiring the user to enter the FQDN of the Administration Node for the cluster

Deficiencies of the CaaSP Installation workflow

Limited System Role Info - No description or help text is provided for any System Roles
Unable to have custom partitioning for a system role - As the partitioning proposal is generated at the point of yast2-caasp loading, it cannot be recalculated based on the system role selected by the user in the same module (jsrain: this could be enhanced in the limits of respective version's partitioner, but was never requested)
No software customisation - No option or capability for selecting custom packages or addressing any package conflicts as part of the installation
No timezone customisation - All CaaSP systems are set to UTC only with no capability of changing it
Lack of common YaST Features - a lot of general YaST features, such as parts of the Driver update stack and reading the registration codes from a USB stick are unavailable due to the yast2-caasp module replacing significant amounts of common YaST functionality

Kubic Installation Overivew

Kubic uses an installation workflow similar to SLE or openSUSE distributions, reusing many of the similar modules but in an abridged fashion. Installation starts, running through the usual analysis modules. The first interactive window is the Beta warning (if applicable), followed by the complex_welcome module

https://openqa.opensuse.org/tests/688773#step/welcome/1

From here users see the following

License
Language
Keyboard Layout

The installation the proceeds to the usual system analysis modules, followed by system_role using the SLE15 version of the System Role module (not the openSUSE equivalent)

https://openqa.opensuse.org/tests/688773#step/system_role/1

From here users receive a list of all system roles including details descriptions. They can select whichever system role they require

The next step of the installation shows the Partition proposal disk_proposal. Unlike in CaaSP, this proposal can be automatically customised in response to the selected System Role, as well as manually customised by the user.

https://openqa.opensuse.org/tests/688773#step/partitioning/1

Next step of the installation is setting the systems root password

https://openqa.opensuse.org/tests/688773#step/user_settings_root/1

Finally the installer shows an Installation Settings page allowing the user to alter/customise the following options

Software selection
Timezone (UTC default)
Network Config
Boot Loader Config
Kdump Config

Installation proceeds like usual

Advantages of Kubic Installation workflow

License is displayed early - The EULA for the software is presented to the user before any installation steps, instead of right before the installation begins
Detailed System Role Info - description and help text is provided for all System Roles
Custom partitioning for system roles - Partitioning changes can be proposed based on selected System Roles
Optional software customization - custom packages or any package conflicts can be addressed as part of the installation
Optional timezone customization - All Kubic systems are set to UTC but can be customized
Ease of Maintenance - All of this installation workflow is using modules used elsewhere in openSUSE or SLE, so benefit from shared maintenance and development of these products.
All common YaST Features - All common YaST features are either available or often easily implementable due to the use of common YaST modules and a similar workflow.

Deficiencies in Kubic Installation workflow

No System Role Specific Installation Steps - Kubic does not have an equivalent of the CaaSP steps outlined in Kubic:CaaSPInstallationComparision#System_Role_Selection
Use Full Disk Obfuscated - Compared to CaaSPv3, the libstorage-ng based guided partitioner requires a significant number of steps to inform the partitioner that the user wishes to use the full disk available, which is likely to be the default behaviour even in many custom Kubic partitioning configurations.
More installation steps - Compared to CaaSPv3, the Kubic workflow required significantly more steps.

Work required to address these issues

No System Role Specific Steps

A yast module (eg. yast2-kubic) to provide an installation step which can grant Kubic the equivalent functionality to Kubic:CaaSPInstallationComparision#System_Role_Selection (jsrain: there should be nothing preventing implementation of custom steps for specific roles)

This could be implemented as a single screen which does one of the following depending on the role selected

Worker Node - Prompt the user for the Administration Node FQDN address
Admin Node - Prompt the user for NTP Server address (Optional for Kubic as openSUSE can use public NTP pools)
Any Other Role - No prompt, no display, continue installation as normal (would act like a yast analysis module)

This module would ideally be run after the system_role screen, but probably before the disk_proposal screen - as the user will most likely associate the additional prompt with the direct choice they just made on the system_role screen.

Use Full Disk Obfuscated

Simplify yast2-storage to have less steps/simpler user experience for using a full disk. Potentially provide control.xml switches to allow Kubic/CaaSP to disable Guided Proposal options which are unlikely to be needed in Kubic/CaaSP (eg. LVM, Encryption, etc) (jsrain: do you need more than setting for Linux, Windows and other partitions to remove even if not needed?)

More Installation Steps

There are some options to be considered to reduce the number of steps from it's current 5 screens (6 once yast2-kubic exists) down to a more acceptable 3 or 4.

Partitioning - Could be removed as a explicit step and instead only shown on the Installation Settings screen
Root Password - Potentially could be implemented as part of a yast2-kubic module, as it is a relatively low risk, low maintenance function compared to many of the others currently melded into the complex yast2-caasp module.

Combined Workflow

The goal of the installer workflow is:

As short as possible, only ask what is really required.
Don't have screens, where the admin will always click "Next" and nobody will change the defaults. Such options should be on the last proposal page.
Use the standard openSUSE and SLE screens to avoid duplicate work and testing and don't miss new YaST features of other products

The workflow would look like:

Language, Keyboard and License Agreement
Registration - SUSE CaaS Platform only
[later] Add Modules - SUSE CaaS Platform only. Only if admin did enter registration code and only online available Modules via SCC/SMT, don't ask for a media. [This is in conflict with FATE#325564:Option to add the repository during CaaSP installation]
System Role - Select the role for the installed system
- Kubic Roles:
  - kubeadm Node
  - openSUSE MicroOS
- CaaSP Roles:
  - Admin/Dashboard
  - Cluster Node
  - Plain System
Role Configuration - Dialog which asks depending on system role for:
- kubeadm Node (Kubic) or Admin/Dashboard (CaaSP)
  - NTP server (chrony) (prefill field with dhcp answer, if there is no dhcp, prefill with ntp pool server if allowed, else leave empty and warn if it stays empty, no hard error)
  - [later] Certificates for velum and API server [1]
    - Certificate for Velum (AI Flavio: where and how to store?)
    - Certificate for kubernetes API (AI Flavio: where and how to store?)
    - Customer CAs [distribute via salt to all nodes?]
- Cluster Node (CaaSP)
  - Name/address of Admin Node
  - NTP client (chrony) (prefill field with dhcp answer, if there is no dhcp, prefill with ntp pool server if allowed, else leave empty and warn if it stays empty, no hard error)
  - [later] [Customer CAs, really needed?]
- openSUSE MicroOS (Kubic) or Plain System (CaaSP)
  - NTP server (chrony) (prefill field with dhcp answer, if there is no dhcp, prefill with ntp pool server if allowed, else leave empty and warn if it stays empty, no hard error)

Root password

Installation Settings
- Partitioning
- Software
- Time Zone
- Network Configuration
- Booting
- Kdump

FATES

325834: New Installer Workflow
325512: Use LANG settings only for YaST2
325564: Option to add the repository during CaaSP installation