[RFC] vdsm-bootstrap rewrite naming

Alon Bar-Lev alonbl at redhat.com
Thu Nov 15 10:34:42 UTC 2012


Hello,

Summary:

Common infrastructure:
OTOPI -- OVirt Task Oriented Pluggable Installer/Implementation.

Deploy code (vdsm-bootstrap):
ovirt-host-deploy

I want to close this by Sunday to perform the rename, split, create repositories etc...

So if anyone has more ideas, please raise a flags as after renaming it will be very difficult to change.

Thanks,
Alon

----- Original Message -----
> From: "Itamar Heim" <iheim at redhat.com>
> To: "Alon Bar-Lev" <alonbl at redhat.com>
> Cc: "arch" <arch at ovirt.org>
> Sent: Thursday, November 15, 2012 12:25:13 PM
> Subject: Re: [RFC] vdsm-bootstrap rewrite naming
> 
> On 11/15/2012 12:22 PM, Alon Bar-Lev wrote:
> > OK, we need to close this up...
> >
> > ----- Original Message -----
> >> From: "Itamar Heim" <iheim at redhat.com>
> >> To: "Alon Bar-Lev" <alonbl at redhat.com>
> >> Cc: "arch" <arch at ovirt.org>
> >> 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.

Great!
So ovirt-host-deploy it is.

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



More information about the Arch mailing list