Mailinglist Archive: yast-devel (91 mails)

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

Dne 27.9.2013 11:49, Johannes Meixner napsal(a):
[...]
- 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 ;-)

Yeah, bad wording, with "completely" and meant rather "do not touch it later",
instead of "configure everything possible".

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.

Yes, that's it.

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).

Yes, the idea is to have a "communication" file, very likely similar to
what AutoYaST uses (XML profile).

I.e. the installer's configuration step must be implemented
so that it can run on any system regardless how that system
was installed.

The configuration should know in advance what it needs and should ask the
installer
to install it in the config step. This is already done in current Yast, e.g.
bootloader can ask the software selection to install Grub (or whatever else is
chosen
for booting) which is configured later after installation


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.

Um, well, there might be additional config files not touched
by installer but still important for configuration.

Example: Yast can configure repositories, install packages, patches... etc,
but libzypp uses zypp.conf config file which is completely ignored by Yast,
so whatever user does wrong there Yast is unable to fix it.

If it works this way, you get a powerful feature for free:
The installer could be used as rescue/recovery tool when a
[...]

Um, maybe as a side effect it could be used this way, but it would not
be 100% reliable (as I mentioned before). We already had a repair tool
in Yast but it was basically unmaintainable.

So I'm skeptic about such "magic repair" functionality for free...

[...]
Probably it helps to implement the installer's 3 basic steps
as three fully separated programs [...]

Yes, it was our idea, but the current decision is to run it one process
if possible (to avoid unnecessary save/load steps, hardware reprobing...)
and run a separate program only when asked to.

To help you a bit, I volunteer for implementing proof of concept
3rd party applications for the install and configure steps.

Yeah, great! That would be nice to have an independent implementation
which we could check against!

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.

Yes, I agree, the backward compatibility with AutoYast and stability is a must.

Perhaps you should make it more clear that "configure the installation"
here and "configure the system" above are fully separated things.
[...]
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.

Yes, exactly.

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.

We basically grouped the values to these groups:

- mandatory (if missing the installer will interactively ask, otherwise
use the predefined value)
- optional (use the value, if missing use a default, don't ask)

And there will be a special "do not touch" value (i.e. keep the current value,
was/will be set by a 3rd party program)

The "do not touch" is useful if you change the install step by your application
(like your proposed wget/tar) then you want to keep some values untouched
because
they might be already configured in the tar file and they would get overwritten.


[...]
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.

Yes, there are more possibilities related to the config file.

One idea was to add support to SUSE Studio to export such config file
as every Studio appliance actually contains the system configuration.
Then you could have an appliance (for direct deployment) and a config
file which could be used as installation template which would allow
custom changes to the installation (compared to the appliance).

Or you could use the appliance in the install step instead of installing from
RPMs
(using your own install step implementation).

Clear separation and the config file open a lot of new possibilities...


Ladislav



--

Ladislav Slez√°k
Appliance department / YaST Developer
Lihovarsk√° 1060/12
190 00 Prague 9 / Czech Republic
tel: +420 284 028 960
lslezak@xxxxxxxx
SUSE
--
To unsubscribe, e-mail: yast-devel+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: yast-devel+owner@xxxxxxxxxxxx

< Previous Next >
Follow Ups