thanks for the info on this, I was out of the office last week but
I'll take a look at it this week and get back to you.
On 10/23/2012 10:13 AM, Alon Bar-Lev wrote:
----- Original Message -----
> From: "Derek Higgins" <derekh(a)redhat.com>
> To: engine-devel(a)ovirt.org
> Sent: Sunday, September 23, 2012 11:36:48 PM
> Subject: [Engine-devel] Splitting out the oVirt engine installer
> Hi All,
> First time poster here so let me know if this is better directed
> some where else
> I have been writing a installer for openstack and as a base for
> I've split out the generic parts of your engine-setup utility.
> In order to do this I've created a generic installer that is
> basically all of the parts of the oVirt engine installer that I
> for my openstack installer
> I'd now like to see if there is interest here to use this generic
> installer for oVirt.
> I may have stripped out some stuff from the installer that I should
> left in, if that is the case I'm open to recreating this repository
> anything generic I shouldn't have stripped out so that the original
> history is maintained. Would anybody here like to look into the work
> necessary to use this installer in oVirt? For openstack I've made
> exclusive use of the plugin functionality and I suspect most changes
> that would be needed for oVirt would be to move a lot of the code
> into a
> similar pattern.
> If you have any questions/comments just let me know, hopefully you
> find this useful and other projects could make use of the great work
> have done developing this setup utility
>  https://github.com/derekhiggins/installer
>  https://github.com/derekhiggins/os-installer
I re-wrote the vdsm-bootstrap, it was very complex and contained much legacy.
It turned out that the vdsm-bootstrap and the engine-setup/engine-upgrade has a lot in
So it is actually a base to any installer.
It is fully plugin, task oriented implementation.
Compatible with python-2.6, python-2.7, python-3.2
Fully localized enabled.
Single session interaction, no file transfer.
Local and remote execution modes are supported.
Distribution independent implementation (core).
The mission is to make it easy as much as possible to add new functionality without the
complexity of the state and transaction management. If you look at the plugins
directories, you will find the business logic, which is about 98% pure.
At the core of the implementation there is environment dictionary and a flow of stages
within plugins. The environment can be modified using command-line parameters,
configuration file, or dialog customization.
At the bottom of this message there is a sample of the dialog between manager and
Although not 100% complete, I will be happy to receive any comment, suggestion and
A snapshot of development sources are available at.
I will be happy to receive your feedback!