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>