Mailinglist Archive: yast-devel (91 mails)

< Previous Next >
Re: [yast-devel] YaST installer - the future development (for 13.2/SLE12, aka "the new installer")

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@xxxxxxxxxxxx
To contact the owner, e-mail: yast-devel+owner@xxxxxxxxxxxx

< Previous Next >
Follow Ups
References