On 11/15/2012 12:22 PM, Alon Bar-Lev wrote:
OK, we need to close this up...
----- Original Message -----
From: "Itamar Heim" <[email protected]>
To: "Alon Bar-Lev" <[email protected]>
Cc: "arch" <[email protected]>
Sent: Tuesday, November 13, 2012 6:21:15 PM
Subject: Re: [RFC] vdsm-bootstrap rewrite naming
On 11/13/2012 01:52 PM, Alon Bar-Lev wrote:
Hello All,
I am working on rewriting the vdsm-bootstrap process.
I found that most of the installer implementation is not vdsm
specific, so I split the package into two:
core installer
vdsm-bootstrap
I would like to find a suitable name for the core installer.
In nat shell:
"""
Standalone plugin based installation framework to be used to setup
system components. The plugin nature provides simplicity to
add new installation functionality without the complexity of the
state
and transaction management.
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.
"""
Sources are available at temporary location[1].
Names that we thought of:
1. ovirt-installer
hmmm, that's between being generic, and consumable by others.
question is how problematic it is if we keep our name...
would be nice if we can advertise ourselves a bit.
maybe we can compromise on:
ogi - ovirt generic installer
so name isn't directly with ovirt, but some marketing of ovirt from
it
may happen.
so +1 to OGI from me.
2. virtulation (virtualization + installation)
3. virtaller (virtualization + installation)
4. TOPI (Task Oriented Pluggable Installer/Implementation)
+1
hmmm, spinning #1:
OTOPI.
has a nice ring to it around utopia as well.
So OTOPI it is, well actually lower case otopi.
5. PDF (Pluggable Deployment Framework)
-1 due to PDF so widely known as something else
I would also like to consider if we want to keep the vdsm-bootstrap
name for the bootstrap package, or we should use something more
generic, as it really bootstrap the host and not vdsm...:
1. ovirt-hypervisor-bootstrap
2. ovirt-host-setup
+1 to this one. not sure if critical to rename the rpm though.
I think that with all alternatives, renaming the package will make it easy
procedurally.
As the old ovirt-engine will continue to pull the existing packages.
We do not need to handle conflicts or breakage.
So can we close up with ovirt-host-setup?
I personally, think ovirt-host-deploy is better than setup.
i'm fine either way.
3. ovirt-deployer
Any other idea will be most welcome, we need to close this fast to
progress.
Best Regards,
Alon Bar-Lev
Thanks!
Alon
_______________________________________________
Arch mailing list
[email protected]
http://lists.ovirt.org/mailman/listinfo/arch
