----- Original Message ----- > From: "Alon Bar-Lev" <[email protected]> > To: "Itamar Heim" <[email protected]> > Cc: "arch" <[email protected]> > 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" <[email protected]> > > To: "Alon Bar-Lev" <[email protected]> > > Cc: "arch" <[email protected]> > > 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" <[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. > > 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 > [email protected] > http://lists.ovirt.org/mailman/listinfo/arch > _______________________________________________ Arch mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/arch
