Hello, On Sep 26 20:07 Ladislav Slezak wrote (excerpt):
Here is the summary of the main goals:
- Remove the second installation stage (started after reboot), configure the system completely just in one stage, after finishing the installer the freshly installed system must be ready to use.
I think the "configure the system completely" is wrong here. ( I assume you would not like to have e.g. printer, scanner, and all kind of system services configuration in the installer ;-) I assume what is meant is: - Remove the second installation stage (started after reboot), do the basic system configuration in one stage, after finishing the installer the freshly installed system must be ready for basic usage. "Basic system configuration for basic usage" means that at least root can log in and do system administration work (e.g. install more software or configure more stuff) and when the system has a network connection then system administration work can also done from remote.
- Separate the installer into 3 basic steps (collect data, install, apply config), make the steps replaceable by 3rd party applications. ^ apply basic system configuration
When those steps should be replaceable by 3rd party applications with reasonable effort for those who make the 3rd party applications those steps must work fully independent from each other. For example the installer's configuration step must not somehow have unexpected/hidden/private dependencies to the previous installer's install step (except the obvious "dependency" that the install step had acually installed the software). I.e. the installer's configuration step must be implemented so that it can run on any system regardless how that system was installed. It must work to install the installer on an already installed system and run only the installer's configuration step there. This would overwrite the existing system's basic configuration by a new system's basic configuration that is the same as if the system would have been installed from scratch. If it works this way, you get a powerful feature for free: The installer could be used as rescue/recovery tool when a system's basic configuration was somehow messed up: Run the installer's configuration step and you get back the system's basic configuration as if the system would have been installed from scratch.
From that well defined know state root can do any system administration work to recover the rest of the messed up system configuration.
I think for the team that implements the installer it could become a major task to continuously keep the installer's 3 basic steps perfectly separated from each other. Probably it helps to implement the installer's 3 basic steps as three fully separated programs (and even provide them in 3 separated RPM packages with no RPM requirements between each other) to ensure that they stay perfectly separated from each other. To help you a bit, I volunteer for implementing proof of concept 3rd party applications for the install and configure steps. My proof-of-concept applications would be bash scripts. My first proof of concept install application would be basically "wget" and "tar" to get and install a backup.tar.gz image that is located on a HTTP server in the network. My first proof of concept configure application would be basically "/bin/true" (i.e. it does actually nothing) because my backup.tar.gz is an already configured system image.
- It should be possible to use the installer just for configuring the installation and exporting the setup into a file (without performing the actual installation). The exported file could be then used to install other system(s). (Like AutoYast does, the new installer will contain some AutoYast functionality).
Related to the 3rd party applications above: That file's format must be stable (both syntax and values must be stable - i.e. only fully backward compatible changes are allowed) so that those 3rd party applications can be implemented with reasonable (maintenance) effort. Perhaps you should make it more clear that "configure the installation" here and "configure the system" above are fully separated things. As far as I understand it "Use the installer for configuring the installation" means: It works to install the installer on an already installed system and run the installer there to only create a configuration for the installation of another system and save that configuration in a file. Then the installation of the other system can be done by using that file. If that file contains a complete configuration of the installation, the installation of the other system can run unattended in a full automated way or it can run in an interactive mode where each value can be modified by a user for the actual installation. If that file does not contain a complete configuration of the installation, the installation of the other system can run either unattended in a full automated way by using fallback values or it can run in an interactive mode where missing values are requested from a user. A special case is when the already installed system and the other system are the same system. Together with the stable file format this could be used to get a new "system upgrade from scratch" feature (again for free): Run the installer in your running openSUSE 13.2 system to create a configuration for the installation that is based on the current running system and save that in a file. Boot your system with the openSUSE 13.3 installer and provide that file to the installer to do a system upgrade from 13.2 to 13.3 from scratch. If the installation runs in interactive mode where each value can be modified by the user for the actual installation, it is easily possible to do fundamental changes that are safer when done during an installation from scratch, for example exchange hardware (e.g. replace the harddisk by a different one) or upgrade of the filesystem (e.g. from ReiserFS to btrfs) or upgrade to the newest bootloader and so on. In the end "system upgrade from scratch" plus fundamental changes result "system migration". One could migrate an existing openSUSE 13.2 system onto a different hardware platform or onto a virtual machine or one could migrate an existing openSUSE 13.2 system into an openSUSE 13.3 system on different hardware and so on. Kind Regards Johannes Meixner -- SUSE LINUX Products GmbH -- Maxfeldstrasse 5 -- 90409 Nuernberg -- Germany HRB 16746 (AG Nuernberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendoerffer -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org