8:42 a.m.
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?
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?
Greetings
fabian
---
[0] https://gerrit.ovirt.org/#/c/40966/
[1] https://gerrit.ovirt.org/gitweb?p=ovirt-register.git
8:48 a.m.
Maybe better is to figure out who requested it to be part of vdsm-tool and why, while
there were open bugs to have standalone tool.
----- Original Message -----
From: "Fabian Deutsch" <fdeutsch(a)redhat.com>
To: "Douglas Landgraf" <dlandgra(a)redhat.com>, "Dan Kenigsberg"
<danken(a)redhat.com>, "Alon Bar-Lev"
<abarlev(a)redhat.com>
Cc: devel(a)ovirt.org
Sent: Wednesday, July 22, 2015 4:42:37 PM
Subject: [ovirt-devel] Registration duplication?
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?
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?
Greetings
fabian
---
[0] https://gerrit.ovirt.org/#/c/40966/
[1] https://gerrit.ovirt.org/gitweb?p=ovirt-register.git
_______________________________________________
Devel mailing list
Devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel
9:59 a.m.
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.
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.
Greetings
fabian
---
[0] https://gerrit.ovirt.org/#/c/40966/
[1] https://gerrit.ovirt.org/gitweb?p=ovirt-register.git
--
Cheers
Douglas
9:04 a.m.
On Wed, Jul 22, 2015 at 4:59 PM, Douglas Schilling Landgraf
<dougsland(a)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.
Thanks
fabian
5:47 a.m.
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(a)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).
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.
5:53 a.m.
----- Original Message -----
From: "Dan Kenigsberg" <danken(a)redhat.com>
To: "Fabian Deutsch" <fdeutsch(a)redhat.com>
Cc: "Alon Bar-Lev" <abarlev(a)redhat.com>, "Douglas Landgraf"
<dlandgra(a)redhat.com>, devel(a)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(a)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(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel
3412
days inactive
3413
days old
5 comments
4 participants
participants (4)
-
Alon Bar-Lev -
Dan Kenigsberg -
Douglas Schilling Landgraf -
Fabian Deutsch