----- Original Message ----- > From: "Dan Kenigsberg" <[email protected]> > To: "Fabian Deutsch" <[email protected]> > Cc: "Alon Bar-Lev" <[email protected]>, "Douglas Landgraf" > <[email protected]>, [email protected] > 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 > > <[email protected]> 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 > [email protected] > http://lists.ovirt.org/mailman/listinfo/devel > _______________________________________________ Devel mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/devel
