Hello,
On Oct 17 11:59 Ladislav Slezak wrote (excerpt):
Dne 17.10.2013 10:40, Johannes Meixner napsal(a):
In particular for SLE it is needed that after a system disaster
the new installer can re-create the system on new (compatible)
replacement hardware as it was before by using a saved config
of the system and deploying one or more backup.tar.gz
images that contain the files of the system.
To support this the new installer has to do those steps:
1. Boot New Machine
2. Use given config (i.e. the saved system config)
3. Disk Activation (e.g. special stuff to make SAN accessible)
4. Storage/Partitioning
5. Create filesystems and mount them at the right mount points
6. Deploy the files (i.e. untar backup.tar.gz images)
So far we thought only about Studio images (raw disk images),
but support for tar.gz is easy so it could be supported as well.
I would very much appreciate it if the new installer supports
deployment via tar.gz.
7. Install bootloader
8. Reboot
Ideally "Deploy the files" should support any mixture of
installing RPMs and whatever kind of software packages
plus untar backup.tar.gz images so that it would be possible
to have only user data in backup.tar.gz but use RPMs for
the basic system software and whatever kind of software
packages for other software like third-party software.
We did not think about this possibility, but it is an
interesting idea to mix both approaches...
Initially the new installer may only support
one type of data for deployment, i.e. deployment
either by installing RPM packages
or by installing an image
or by untar of a tar.gz archive.
For my particular use case "system recovery" it would be
basically sufficient to untar a single tar.gz archive
(which means the user must backup all in one single archive).
But when the new installer supports each of those types of data
for deployment, then - I think - it should be relatively easy
to also support any mixture of those types.
The precondition is that the deployment step works well separated
from the other steps - i.e. that the deployment step can work
basically on its own.
Then it should be relatively easy to run several deployment steps
one after the other.
To do this the config file must support to define several deployment
steps and the sequence when each step should run.
For example (config in XML-like syntax):
----------------------------------------------------------------------
<deployments>
<deployment>
<deployment_sequence_number>10</deployment_sequence_number>
<deployment_data_type>image</deployment_data_type>
<image_uri>ftp://server/base_system_image.raw</image_uri>
</deployment>
<deployment>
<deployment_sequence_number>11</deployment_sequence_number>
<deployment_data_type>rpm</deployment_data_type>
<repositories>
<repository>cdrom</repository>
<repository>http://server/...</repository>
</repositories>
<packages>
<package>apache2-prefork</package>
<package>apache2-doc</package>
</packages>
</deployment>
<deployment>
<deployment_sequence_number>20</deployment_sequence_number>
<deployment_data_type>tgz</deployment_data_type>
<tgz_uri>nfs://server/system_config_data.tar.gz</tgz_uri>
</deployment>
<deployment>
<deployment_sequence_number>20</deployment_sequence_number>
<deployment_data_type>tgz</deployment_data_type>
<tgz_uri>https://server/user_data.tar.gz</tgz_uri>
</deployment>
<deployment>
<deployment_sequence_number>90</deployment_sequence_number>
<deployment_data_type>script</deployment_data_type>
<script_uri>/home/admin/install_3rdparty_database.sh</script_uri>
</deployment>
<deployment>
<deployment_sequence_number>91</deployment_sequence_number>
<deployment_data_type>tgz</deployment_data_type>
<tgz_uri>smb://server/database_data.tar.gz</tgz_uri>
</deployment>
</deployments>
----------------------------------------------------------------------
This would run the following deployment steps:
1. The basic system gets installed as an image
from ftp://server/base_system_image.raw
2. On top of the basic system additional software like Apache
gets installed as RPM packages.
3. Deployment steps with same sequence number run simultaneously
where one installs system config data (e.g. the Apache config)
and the other one installs user data (e.g. home directories)
by untar of two tar.gz archives in parallel.
4. On top of that a third party database gets installed
by running a script from the admin's home directory.
5. Finally the database data gets installed
by untar of a tar.gz archive.
As far as I understand your current proposal there is another
major difference of my proposal compared to your proposal:
In your current proposal one would need to replace the whole
deployment step if one needs to do any (possibly tiny) special
stuff by running a selfmade script.
In contrast in my proposal running a selfmade script would be
supported by the deployment module of the new installer.
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: [email protected]
To contact the owner, e-mail: [email protected]
