[RFC] vdsm-bootstrap rewrite naming

[Alon Bar-Lev]

----- Original Message -----
> From: "Alon Bar-Lev" <alonbl at redhat.com>
> To: "Itamar Heim" <iheim at redhat.com>
> Cc: "arch" <arch at ovirt.org>
> Sent: Thursday, November 15, 2012 12:34:42 PM
> Subject: Re: [RFC] vdsm-bootstrap rewrite naming
> 
> 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

I forgot we need a namespace for the core specific java resources.

Should it be org.ovirt.otopi or drop the ovirt in favour of org.otopi?

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
> > >
> > 
> > 
> > 
> _______________________________________________
> Arch mailing list
> Arch at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/arch
>