[ovirt-devel] Registration duplication?

[Alon Bar-Lev]

----- Original Message -----
> From: "Dan Kenigsberg" <danken at redhat.com>
> To: "Fabian Deutsch" <fdeutsch at redhat.com>
> Cc: "Alon Bar-Lev" <abarlev at redhat.com>, "Douglas Landgraf" <dlandgra at redhat.com>, devel at ovirt.org
> Sent: Thursday, July 23, 2015 1:47:04 PM
> Subject: Re: [ovirt-devel] Registration duplication?
> 
> On Wed, Jul 22, 2015 at 04:04:38PM +0200, Fabian Deutsch wrote:
> > On Wed, Jul 22, 2015 at 4:59 PM, Douglas Schilling Landgraf
> > <dougsland at redhat.com> wrote:
> > > On 07/22/2015 09:42 AM, Fabian Deutsch wrote:
> > >>
> > >> Hey,
> > >>
> > >> I've seen that some new code landed to support Engine registration
> > >> using the generic registration approach.
> > >>
> > >> But it seem that we now have two implementations:
> > >>
> > >> 1. vdsm-tool register [0]
> > >> 2. ovirt-register [1]
> > >>
> > >> To reduce code duplication I'd suggest to drop one of these approaches
> > >> before we enter 3.6.
> > >> Or are there reasons for keeping both of them?
> > >
> > > I believe not.
> > 
> > Great.
> > 
> > >> My take is to keep ovirt-register which is independent and would allow
> > >> us to add plain hosts to Engine (host-deploy is then taking care of
> > >> the rest IIUIC).
> > >> The vdsm-tool approach reuqires vdsm to be installed.
> > >>
> > >> Thoughts?
> > >
> > >
> > > +1 for dropping vdsm-tool register verb. It started as alternative and
> > > later
> > > we merged everything in ovirt-register project which is the generic
> > > registration. I can send a patch to drop it soon.
> > 
> > Right.
> > So let's see what Dan replies and then we can possibly drop the
> > duplicate effort.
> 
> To answer properly, I'll need to know about the current state of
> ovirt-register.
> 
> Is ready and available? I know that long ago someone opened complex
> RFEs for it, but the implementation never got into fruition.
> 
> I'd like to see vdsm-reg gone, and I'd like to see it gone now. With
> vdsm-tool register merged, I don't think there's any remaining effort on
> that front (except of removing the dead vdsm-reg code out of vdsm, but
> this applies to both).

vdsm-reg can be gone only when entire functionality is provided, such as PXE, kernel parameters and service.

so a simple hack of vdsm-tool is not the solution.

please do not address me as "someone".

if you had comments about the design, you should have noted before you took parallel incomplete actions.

> 
> I don't mind at all seeing ovirt-node use ovirt-register instead of
> vdsm-tool, and I wouldn't realy care if `vdsm-tool register`'s
> implementation is scrapped in favor of calling ovirt-register.
> 
> Dan.
> _______________________________________________
> Devel mailing list
> Devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
>