6:13 a.m.
Hi all,
We should not support now Engine 3.5 with ovirt 4.0, but vdsm still
accept 3.5 engines - I guess we forgot to disable it in 4.0.
In 4.1, I don't think we should support any 3.x Engine - otherwise we
will have to waste time maintaining old apis and infrastructure, instead
of adding new features that matter to our users.
I suggest we disable now support for 3.x engines.
Please see Eli patch:
https://gerrit.ovirt.org/59308
Thoughts?
Nir
7:40 a.m.
On Sun, Jun 19, 2016 at 02:13:40PM +0300, Nir Soffer wrote:
Hi all,
We should not support now Engine 3.5 with ovirt 4.0, but vdsm still
accept 3.5 engines - I guess we forgot to disable it in 4.0.
Correct. There was a moment in time where we considered supporting 3.5
as well.
In 4.1, I don't think we should support any 3.x Engine - otherwise we
will have to waste time maintaining old apis and infrastructure, instead
of adding new features that matter to our users.
Do you have a list of old APIs you'd like to throw away? We've killed a
few in 4.0, and
$ git grep REQUIRED_FOR
is not huge.
I suggest we disable now support for 3.x engines.
Please see Eli patch:
https://gerrit.ovirt.org/59308
Thoughts?
+1, but let's see if ydary/mgoldboi think we should keep 3.6.
8 a.m.
What is the cost of keeping them?
Yaniv Dary
Technical Product Manager
Red Hat Israel Ltd.
34 Jerusalem Road
Building A, 4th floor
Ra'anana, Israel 4350109
Tel : +972 (9) 7692306
8272306
Email: ydary(a)redhat.com
IRC : ydary
On Sun, Jun 19, 2016 at 3:40 PM, Dan Kenigsberg <danken(a)redhat.com> wrote:
On Sun, Jun 19, 2016 at 02:13:40PM +0300, Nir Soffer wrote:
> Hi all,
>
> We should not support now Engine 3.5 with ovirt 4.0, but vdsm still
> accept 3.5 engines - I guess we forgot to disable it in 4.0.
Correct. There was a moment in time where we considered supporting 3.5
as well.
>
> In 4.1, I don't think we should support any 3.x Engine - otherwise we
> will have to waste time maintaining old apis and infrastructure, instead
> of adding new features that matter to our users.
Do you have a list of old APIs you'd like to throw away? We've killed a
few in 4.0, and
$ git grep REQUIRED_FOR
is not huge.
>
> I suggest we disable now support for 3.x engines.
>
> Please see Eli patch:
> https://gerrit.ovirt.org/59308
>
> Thoughts?
+1, but let's see if ydary/mgoldboi think we should keep 3.6.
8:06 a.m.
my pov - really depends on when do we release 4.1.
short version (Dec 16) - we should keep it, and 3.6 api as well
long version (Mar 17) - let's drop it than.
bottom line - we would like to give customers/community the time to migrate
their el6 base deployment to el7 , while allowing them dual management
infra. by march next year we should be in the 7.4/.next timeframe - this
should be ok to our conservative customer base as well
On Sun, Jun 19, 2016 at 4:00 PM, Yaniv Dary <ydary(a)redhat.com> wrote:
What is the cost of keeping them?
Yaniv Dary
Technical Product Manager
Red Hat Israel Ltd.
34 Jerusalem Road
Building A, 4th floor
Ra'anana, Israel 4350109
Tel : +972 (9) 7692306
8272306
Email: ydary(a)redhat.com
IRC : ydary
On Sun, Jun 19, 2016 at 3:40 PM, Dan Kenigsberg <danken(a)redhat.com> wrote:
> On Sun, Jun 19, 2016 at 02:13:40PM +0300, Nir Soffer wrote:
> > Hi all,
> >
> > We should not support now Engine 3.5 with ovirt 4.0, but vdsm still
> > accept 3.5 engines - I guess we forgot to disable it in 4.0.
>
> Correct. There was a moment in time where we considered supporting 3.5
> as well.
>
> >
> > In 4.1, I don't think we should support any 3.x Engine - otherwise we
> > will have to waste time maintaining old apis and infrastructure, instead
> > of adding new features that matter to our users.
>
> Do you have a list of old APIs you'd like to throw away? We've killed a
> few in 4.0, and
> $ git grep REQUIRED_FOR
> is not huge.
>
> >
> > I suggest we disable now support for 3.x engines.
> >
> > Please see Eli patch:
> > https://gerrit.ovirt.org/59308
> >
> > Thoughts?
>
> +1, but let's see if ydary/mgoldboi think we should keep 3.6.
>
4:30 a.m.
--Apple-Mail=_F7420601-C321-4F16-BEEE-0C3903603AB0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=us-ascii
On 19 Jun 2016, at 15:06, Moran Goldboim <mgoldboi(a)redhat.com>
wrote:
=20
my pov - really depends on when do we release 4.1.
short version (Dec 16) - we should keep it, and 3.6 api as well
long version (Mar 17) - let's drop it than.
I would concur
So we need a decision regarding short vs long 4.1 ASAP
=20
bottom line - we would like to give customers/community the time to =
migrate their
el6 base deployment to el7 , while allowing them dual =
management infra. by march next year we should be in the 7.4/.next =
timeframe - this should be ok to our conservative customer base as well
=20
On Sun, Jun 19, 2016 at 4:00 PM, Yaniv Dary <ydary(a)redhat.com =
<mailto:ydary@redhat.com>> wrote:
What is the cost of keeping them?
The cost of having to live with legacy code is always high
Thanks,
michal
=20
Yaniv Dary
Technical Product Manager
Red Hat Israel Ltd.
34 Jerusalem Road
Building A, 4th floor
Ra'anana, Israel 4350109
=20
Tel : +972 (9) 7692306 <tel:%2B972%20%289%29%207692306>
8272306
Email: ydary(a)redhat.com <mailto:ydary@redhat.com>
IRC : ydary
=20
On Sun, Jun 19, 2016 at 3:40 PM, Dan Kenigsberg <danken(a)redhat.com =
<mailto:danken@redhat.com>> wrote:
On Sun, Jun 19, 2016 at 02:13:40PM +0300, Nir Soffer wrote:
> Hi all,
>
> We should not support now Engine 3.5 with ovirt 4.0, but vdsm still
> accept 3.5 engines - I guess we forgot to disable it in 4.0.
=20
Correct. There was a moment in time where we considered supporting 3.5
as well.
=20
>
> In 4.1, I don't think we should support any 3.x Engine - otherwise =
we
> will have to waste time maintaining old apis and infrastructure,
=
instead
> of adding new features that matter to our users.
=20
Do you have a list of old APIs you'd like to throw away? We've killed =
a
few in 4.0, and
$ git grep REQUIRED_FOR
is not huge.
=20
>
> I suggest we disable now support for 3.x engines.
>
> Please see Eli patch:
> https://gerrit.ovirt.org/59308 <https://gerrit.ovirt.org/59308>
>
> Thoughts?
=20
+1, but let's see if ydary/mgoldboi think we should keep 3.6.
=20
=20
_______________________________________________
Devel mailing list
Devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel
--Apple-Mail=_F7420601-C321-4F16-BEEE-0C3903603AB0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
charset=us-ascii
<html><head><meta http-equiv=3D"Content-Type"
content=3D"text/html =
charset=3Dus-ascii"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" =
class=3D""><br class=3D""><div><blockquote
type=3D"cite" class=3D""><div =
class=3D"">On 19 Jun 2016, at 15:06, Moran Goldboim <<a =
href=3D"mailto:mgoldboi@redhat.com"
class=3D"">mgoldboi(a)redhat.com</a>&gt;=
wrote:</div><br class=3D"Apple-interchange-newline"><div
class=3D""><div =
dir=3D"ltr" class=3D""><div class=3D""><div
class=3D""><div class=3D"">my =
pov - really depends on when do we release 4.1.<br
class=3D""></div>short =
version (Dec 16) - we should keep it, and 3.6 api as well<br =
class=3D""></div>long version (Mar 17) - let's drop it than.<br
=
class=3D""></div></div></div></blockquote><div><br
class=3D""></div>I =
would concur</div><div>So we need a decision regarding short vs long 4.1 =
ASAP</div><div><br class=3D""><blockquote
type=3D"cite" class=3D""><div =
class=3D""><div dir=3D"ltr" class=3D""><div
class=3D""><br =
class=3D""></div>bottom line - we would like to give
customers/community =
the time to migrate their el6 base deployment to el7 , while allowing =
them dual management infra. by march next year we should be in the =
7.4/.next timeframe - this should be ok to our conservative customer =
base as well</div></div></blockquote><blockquote
type=3D"cite" =
class=3D""><div class=3D""><div
class=3D"gmail_extra"><br class=3D""><div =
class=3D"gmail_quote">On Sun, Jun 19, 2016 at 4:00 PM, Yaniv Dary <span =
dir=3D"ltr" class=3D""><<a
href=3D"mailto:ydary@redhat.com" =
target=3D"_blank"
class=3D"">ydary(a)redhat.com</a>&gt;</span> wrote:<br =
class=3D""><blockquote class=3D"gmail_quote"
style=3D"margin:0 0 0 =
.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr" =
class=3D"">What is the cost of keeping =
them?</div></blockquote></div></div></div></blockquote><div><br
=
class=3D""></div>The cost of having to live with legacy code is always
=
high</div><div><br =
class=3D""></div><div>Thanks,</div><div>michal</div><div><br
=
class=3D""><blockquote type=3D"cite"
class=3D""><div class=3D""><div =
class=3D"gmail_extra"><div
class=3D"gmail_quote"><blockquote =
class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex"><div class=3D"gmail_extra"><br
clear=3D"all" =
class=3D""><div class=3D""><div
data-smartmail=3D"gmail_signature" =
class=3D""><div dir=3D"ltr" class=3D""><div
class=3D""><div dir=3D"ltr" =
class=3D""><pre cols=3D"72" class=3D""><span =
style=3D"font-family:arial,helvetica,sans-serif" class=3D"">Yaniv
Dary
Technical Product Manager
Red Hat Israel Ltd.
34 Jerusalem Road
Building A, 4th floor
Ra'anana, Israel 4350109
Tel : <a href=3D"tel:%2B972%20%289%29%207692306"
value=3D"+97297692306" =
target=3D"_blank" class=3D"">+972 (9) 7692306</a>
8272306
Email: <a href=3D"mailto:ydary@redhat.com" target=3D"_blank" =
class=3D"">ydary(a)redhat.com</a>
IRC : ydary</span></pre>
</div></div></div></div></div><div
class=3D""><div class=3D"h5">
<br class=3D""><div class=3D"gmail_quote">On Sun, Jun 19,
2016 at 3:40 =
PM, Dan Kenigsberg <span dir=3D"ltr" class=3D""><<a =
href=3D"mailto:danken@redhat.com" target=3D"_blank" =
class=3D"">danken(a)redhat.com</a>&gt;</span> wrote:<br =
class=3D""><blockquote class=3D"gmail_quote"
style=3D"margin:0 0 0 =
.8ex;border-left:1px #ccc solid;padding-left:1ex"><span
class=3D"">On =
Sun, Jun 19, 2016 at 02:13:40PM +0300, Nir Soffer wrote:<br class=3D"">
> Hi all,<br class=3D"">
><br class=3D"">
> We should not support now Engine 3.5 with ovirt 4.0, but vdsm =
still<br class=3D"">
> accept 3.5 engines - I guess we forgot to disable it in 4.0.<br =
class=3D"">
<br class=3D"">
</span>Correct. There was a moment in time where we considered =
supporting 3.5<br class=3D"">
as well.<br class=3D"">
<span class=3D""><br class=3D"">
><br class=3D"">
> In 4.1, I don't think we should support any 3.x Engine - otherwise =
we<br class=3D"">
> will have to waste time maintaining old apis and infrastructure, =
instead<br class=3D"">
> of adding new features that matter to our users.<br class=3D"">
<br class=3D"">
</span>Do you have a list of old APIs you'd like to throw away? We've =
killed a<br class=3D"">
few in 4.0, and<br class=3D"">
$ git grep REQUIRED_FOR<br class=3D"">
is not huge.<br class=3D"">
<span class=3D""><br class=3D"">
><br class=3D"">
> I suggest we disable now support for 3.x engines.<br class=3D"">
><br class=3D"">
> Please see Eli patch:<br class=3D"">
> <a href=3D"https://gerrit.ovirt.org/59308"
rel=3D"noreferrer" =
target=3D"_blank"
class=3D"">https://gerrit.ovirt.org/59308</a><br =
class=3D"">
><br class=3D"">
> Thoughts?<br class=3D"">
<br class=3D"">
</span>+1, but let's see if ydary/mgoldboi think we should keep 3.6.<br =
class=3D"">
</blockquote></div><br
class=3D""></div></div></div>
</blockquote></div><br class=3D""></div>
_______________________________________________<br class=3D"">Devel =
mailing list<br class=3D""><a href=3D"mailto:Devel@ovirt.org"
=
class=3D"">Devel(a)ovirt.org</a><br =
class=3D"">http://lists.ovirt.org/mailman/listinfo/devel<...
</div><br class=3D""></body></html>=
--Apple-Mail=_F7420601-C321-4F16-BEEE-0C3903603AB0--
1:39 a.m.
On Sun, Jun 19, 2016 at 3:06 PM, Moran Goldboim <mgoldboi(a)redhat.com> wrote:
my pov - really depends on when do we release 4.1.
short version (Dec 16) - we should keep it, and 3.6 api as well
long version (Mar 17) - let's drop it than.
bottom line - we would like to give customers/community the time to
migrate their el6 base deployment to el7 , while allowing them dual
management infra. by march next year we should be in the 7.4/.next
timeframe - this should be ok to our conservative customer base as well
el6 to el7 host migration should have been done in 3.5. 3.6 doesn't support
el6 as hosts...
On Sun, Jun 19, 2016 at 4:00 PM, Yaniv Dary <ydary(a)redhat.com> wrote:
> What is the cost of keeping them?
>
> Yaniv Dary
> Technical Product Manager
> Red Hat Israel Ltd.
> 34 Jerusalem Road
> Building A, 4th floor
> Ra'anana, Israel 4350109
>
> Tel : +972 (9) 7692306
> 8272306
> Email: ydary(a)redhat.com
> IRC : ydary
>
>
> On Sun, Jun 19, 2016 at 3:40 PM, Dan Kenigsberg <danken(a)redhat.com>
> wrote:
>
>> On Sun, Jun 19, 2016 at 02:13:40PM +0300, Nir Soffer wrote:
>> > Hi all,
>> >
>> > We should not support now Engine 3.5 with ovirt 4.0, but vdsm still
>> > accept 3.5 engines - I guess we forgot to disable it in 4.0.
>>
>> Correct. There was a moment in time where we considered supporting 3.5
>> as well.
>>
>> >
>> > In 4.1, I don't think we should support any 3.x Engine - otherwise we
>> > will have to waste time maintaining old apis and infrastructure,
>> instead
>> > of adding new features that matter to our users.
>>
>> Do you have a list of old APIs you'd like to throw away? We've killed a
>> few in 4.0, and
>> $ git grep REQUIRED_FOR
>> is not huge.
>>
>> >
>> > I suggest we disable now support for 3.x engines.
>> >
>> > Please see Eli patch:
>> > https://gerrit.ovirt.org/59308
>> >
>> > Thoughts?
>>
>> +1, but let's see if ydary/mgoldboi think we should keep 3.6.
>>
>
>
_______________________________________________
Devel mailing list
Devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel
--
Sandro Bonazzola
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com
2:05 a.m.
On Tue, Jun 21, 2016 at 9:39 AM, Sandro Bonazzola <sbonazzo(a)redhat.com>
wrote:
On Sun, Jun 19, 2016 at 3:06 PM, Moran Goldboim <mgoldboi(a)redhat.com>
wrote:
> my pov - really depends on when do we release 4.1.
> short version (Dec 16) - we should keep it, and 3.6 api as well
> long version (Mar 17) - let's drop it than.
>
> bottom line - we would like to give customers/community the time to
> migrate their el6 base deployment to el7 , while allowing them dual
> management infra. by march next year we should be in the 7.4/.next
> timeframe - this should be ok to our conservative customer base as well
>
el6 to el7 host migration should have been done in 3.5. 3.6 doesn't
support el6 as hosts...
busted here - you are right.. :)
the main point is to allow this deprecation to happen form our integration
projects and users side. if we will release early - i would suggest to keep
the support for additional version.
>
> On Sun, Jun 19, 2016 at 4:00 PM, Yaniv Dary <ydary(a)redhat.com> wrote:
>
>> What is the cost of keeping them?
>>
>> Yaniv Dary
>> Technical Product Manager
>> Red Hat Israel Ltd.
>> 34 Jerusalem Road
>> Building A, 4th floor
>> Ra'anana, Israel 4350109
>>
>> Tel : +972 (9) 7692306
>> 8272306
>> Email: ydary(a)redhat.com
>> IRC : ydary
>>
>>
>> On Sun, Jun 19, 2016 at 3:40 PM, Dan Kenigsberg <danken(a)redhat.com>
>> wrote:
>>
>>> On Sun, Jun 19, 2016 at 02:13:40PM +0300, Nir Soffer wrote:
>>> > Hi all,
>>> >
>>> > We should not support now Engine 3.5 with ovirt 4.0, but vdsm still
>>> > accept 3.5 engines - I guess we forgot to disable it in 4.0.
>>>
>>> Correct. There was a moment in time where we considered supporting 3.5
>>> as well.
>>>
>>> >
>>> > In 4.1, I don't think we should support any 3.x Engine - otherwise
we
>>> > will have to waste time maintaining old apis and infrastructure,
>>> instead
>>> > of adding new features that matter to our users.
>>>
>>> Do you have a list of old APIs you'd like to throw away? We've killed
a
>>> few in 4.0, and
>>> $ git grep REQUIRED_FOR
>>> is not huge.
>>>
>>> >
>>> > I suggest we disable now support for 3.x engines.
>>> >
>>> > Please see Eli patch:
>>> > https://gerrit.ovirt.org/59308
>>> >
>>> > Thoughts?
>>>
>>> +1, but let's see if ydary/mgoldboi think we should keep 3.6.
>>>
>>
>>
>
> _______________________________________________
> Devel mailing list
> Devel(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
>
--
Sandro Bonazzola
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com
3:20 a.m.
On Tue, Jun 21, 2016 at 10:05 AM, Moran Goldboim <mgoldboi(a)redhat.com>
wrote:
On Tue, Jun 21, 2016 at 9:39 AM, Sandro Bonazzola <sbonazzo(a)redhat.com>
wrote:
>
>
> On Sun, Jun 19, 2016 at 3:06 PM, Moran Goldboim <mgoldboi(a)redhat.com>
> wrote:
>
>> my pov - really depends on when do we release 4.1.
>> short version (Dec 16) - we should keep it, and 3.6 api as well
>> long version (Mar 17) - let's drop it than.
>>
>> bottom line - we would like to give customers/community the time to
>> migrate their el6 base deployment to el7 , while allowing them dual
>> management infra. by march next year we should be in the 7.4/.next
>> timeframe - this should be ok to our conservative customer base as well
>>
>
> el6 to el7 host migration should have been done in 3.5. 3.6 doesn't
> support el6 as hosts...
>
>
busted here - you are right.. :)
the main point is to allow this deprecation to happen form our integration
projects and users side. if we will release early - i would suggest to keep
the support for additional version.
Keep support for what exactly? What can use the XML-RPC but our own
internal tools (such as MOM) which we'll convert?
Y.
>
>
>
>>
>> On Sun, Jun 19, 2016 at 4:00 PM, Yaniv Dary <ydary(a)redhat.com> wrote:
>>
>>> What is the cost of keeping them?
>>>
>>> Yaniv Dary
>>> Technical Product Manager
>>> Red Hat Israel Ltd.
>>> 34 Jerusalem Road
>>> Building A, 4th floor
>>> Ra'anana, Israel 4350109
>>>
>>> Tel : +972 (9) 7692306
>>> 8272306
>>> Email: ydary(a)redhat.com
>>> IRC : ydary
>>>
>>>
>>> On Sun, Jun 19, 2016 at 3:40 PM, Dan Kenigsberg <danken(a)redhat.com>
>>> wrote:
>>>
>>>> On Sun, Jun 19, 2016 at 02:13:40PM +0300, Nir Soffer wrote:
>>>> > Hi all,
>>>> >
>>>> > We should not support now Engine 3.5 with ovirt 4.0, but vdsm still
>>>> > accept 3.5 engines - I guess we forgot to disable it in 4.0.
>>>>
>>>> Correct. There was a moment in time where we considered supporting 3.5
>>>> as well.
>>>>
>>>> >
>>>> > In 4.1, I don't think we should support any 3.x Engine -
otherwise we
>>>> > will have to waste time maintaining old apis and infrastructure,
>>>> instead
>>>> > of adding new features that matter to our users.
>>>>
>>>> Do you have a list of old APIs you'd like to throw away? We've
killed a
>>>> few in 4.0, and
>>>> $ git grep REQUIRED_FOR
>>>> is not huge.
>>>>
>>>> >
>>>> > I suggest we disable now support for 3.x engines.
>>>> >
>>>> > Please see Eli patch:
>>>> > https://gerrit.ovirt.org/59308
>>>> >
>>>> > Thoughts?
>>>>
>>>> +1, but let's see if ydary/mgoldboi think we should keep 3.6.
>>>>
>>>
>>>
>>
>> _______________________________________________
>> Devel mailing list
>> Devel(a)ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/devel
>>
>
>
>
> --
> Sandro Bonazzola
> Better technology. Faster innovation. Powered by community collaboration.
> See how it works at redhat.com
>
_______________________________________________
Devel mailing list
Devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel
3:26 a.m.
On Tue, Jun 21, 2016 at 11:20 AM, Yaniv Kaul <ykaul(a)redhat.com> wrote:
On Tue, Jun 21, 2016 at 10:05 AM, Moran Goldboim
<mgoldboi(a)redhat.com>
wrote:
>
>
> On Tue, Jun 21, 2016 at 9:39 AM, Sandro Bonazzola <sbonazzo(a)redhat.com>
> wrote:
>
>>
>>
>> On Sun, Jun 19, 2016 at 3:06 PM, Moran Goldboim <mgoldboi(a)redhat.com>
>> wrote:
>>
>>> my pov - really depends on when do we release 4.1.
>>> short version (Dec 16) - we should keep it, and 3.6 api as well
>>> long version (Mar 17) - let's drop it than.
>>>
>>> bottom line - we would like to give customers/community the time to
>>> migrate their el6 base deployment to el7 , while allowing them dual
>>> management infra. by march next year we should be in the 7.4/.next
>>> timeframe - this should be ok to our conservative customer base as well
>>>
>>
>> el6 to el7 host migration should have been done in 3.5. 3.6 doesn't
>> support el6 as hosts...
>>
>>
> busted here - you are right.. :)
> the main point is to allow this deprecation to happen form our
> integration projects and users side. if we will release early - i would
> suggest to keep the support for additional version.
>
Keep support for what exactly? What can use the XML-RPC but our own
internal tools (such as MOM) which we'll convert?
Y.
I was referring to 3.6 engine (part of 3.x engines..)- api.
i don't think we should support 3.5 or xml-rpc.
>
>
>
>>
>>
>>
>>>
>>> On Sun, Jun 19, 2016 at 4:00 PM, Yaniv Dary <ydary(a)redhat.com> wrote:
>>>
>>>> What is the cost of keeping them?
>>>>
>>>> Yaniv Dary
>>>> Technical Product Manager
>>>> Red Hat Israel Ltd.
>>>> 34 Jerusalem Road
>>>> Building A, 4th floor
>>>> Ra'anana, Israel 4350109
>>>>
>>>> Tel : +972 (9) 7692306
>>>> 8272306
>>>> Email: ydary(a)redhat.com
>>>> IRC : ydary
>>>>
>>>>
>>>> On Sun, Jun 19, 2016 at 3:40 PM, Dan Kenigsberg
<danken(a)redhat.com>
>>>> wrote:
>>>>
>>>>> On Sun, Jun 19, 2016 at 02:13:40PM +0300, Nir Soffer wrote:
>>>>> > Hi all,
>>>>> >
>>>>> > We should not support now Engine 3.5 with ovirt 4.0, but vdsm
still
>>>>> > accept 3.5 engines - I guess we forgot to disable it in 4.0.
>>>>>
>>>>> Correct. There was a moment in time where we considered supporting
3.5
>>>>> as well.
>>>>>
>>>>> >
>>>>> > In 4.1, I don't think we should support any 3.x Engine -
otherwise
>>>>> we
>>>>> > will have to waste time maintaining old apis and
infrastructure,
>>>>> instead
>>>>> > of adding new features that matter to our users.
>>>>>
>>>>> Do you have a list of old APIs you'd like to throw away?
We've killed
>>>>> a
>>>>> few in 4.0, and
>>>>> $ git grep REQUIRED_FOR
>>>>> is not huge.
>>>>>
>>>>> >
>>>>> > I suggest we disable now support for 3.x engines.
>>>>> >
>>>>> > Please see Eli patch:
>>>>> > https://gerrit.ovirt.org/59308
>>>>> >
>>>>> > Thoughts?
>>>>>
>>>>> +1, but let's see if ydary/mgoldboi think we should keep 3.6.
>>>>>
>>>>
>>>>
>>>
>>> _______________________________________________
>>> Devel mailing list
>>> Devel(a)ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/devel
>>>
>>
>>
>>
>> --
>> Sandro Bonazzola
>> Better technology. Faster innovation. Powered by community collaboration.
>> See how it works at redhat.com
>>
>
>
> _______________________________________________
> Devel mailing list
> Devel(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
>
11:30 a.m.
On Sun, Jun 19, 2016 at 4:00 PM, Yaniv Dary <ydary(a)redhat.com> wrote:
What is the cost of keeping them?
Hard to tell, I guess each time you touch code related to the api,
your effort is
doubled.
Yaniv Dary
Technical Product Manager
Red Hat Israel Ltd.
34 Jerusalem Road
Building A, 4th floor
Ra'anana, Israel 4350109
Tel : +972 (9) 7692306
8272306
Email: ydary(a)redhat.com
IRC : ydary
On Sun, Jun 19, 2016 at 3:40 PM, Dan Kenigsberg <danken(a)redhat.com> wrote:
>
> On Sun, Jun 19, 2016 at 02:13:40PM +0300, Nir Soffer wrote:
> > Hi all,
> >
> > We should not support now Engine 3.5 with ovirt 4.0, but vdsm still
> > accept 3.5 engines - I guess we forgot to disable it in 4.0.
>
> Correct. There was a moment in time where we considered supporting 3.5
> as well.
>
> >
> > In 4.1, I don't think we should support any 3.x Engine - otherwise we
> > will have to waste time maintaining old apis and infrastructure, instead
> > of adding new features that matter to our users.
>
> Do you have a list of old APIs you'd like to throw away? We've killed a
> few in 4.0, and
> $ git grep REQUIRED_FOR
> is not huge.
>
> >
> > I suggest we disable now support for 3.x engines.
> >
> > Please see Eli patch:
> > https://gerrit.ovirt.org/59308
> >
> > Thoughts?
>
> +1, but let's see if ydary/mgoldboi think we should keep 3.6.
11:49 a.m.
On Sun, Jun 19, 2016 at 3:40 PM, Dan Kenigsberg <danken(a)redhat.com> wrote:
On Sun, Jun 19, 2016 at 02:13:40PM +0300, Nir Soffer wrote:
> Hi all,
>
> We should not support now Engine 3.5 with ovirt 4.0, but vdsm still
> accept 3.5 engines - I guess we forgot to disable it in 4.0.
Correct. There was a moment in time where we considered supporting 3.5
as well.
Ok, so we can remove now 3.5 support, and backport it to 4.0.
> In 4.1, I don't think we should support any 3.x Engine -
otherwise we
> will have to waste time maintaining old apis and infrastructure, instead
> of adding new features that matter to our users.
Do you have a list of old APIs you'd like to throw away? We've killed a
few in 4.0, and
$ git grep REQUIRED_FOR
is not huge.
I don't think we have many verbs to remove, it is mainly about rotten
infrastructure that we can delete or simplify.
Nir
>
> I suggest we disable now support for 3.x engines.
>
> Please see Eli patch:
> https://gerrit.ovirt.org/59308
>
> Thoughts?
+1, but let's see if ydary/mgoldboi think we should keep 3.6.
12:53 p.m.
On Mon, Jun 20, 2016 at 7:49 PM, Nir Soffer <nsoffer(a)redhat.com> wrote:
On Sun, Jun 19, 2016 at 3:40 PM, Dan Kenigsberg
<danken(a)redhat.com> wrote:
> On Sun, Jun 19, 2016 at 02:13:40PM +0300, Nir Soffer wrote:
>> Hi all,
>>
>> We should not support now Engine 3.5 with ovirt 4.0, but vdsm still
>> accept 3.5 engines - I guess we forgot to disable it in 4.0.
>
> Correct. There was a moment in time where we considered supporting 3.5
> as well.
Ok, so we can remove now 3.5 support, and backport it to 4.0.
Posted https://gerrit.ovirt.org/59504 , please ack.
>> In 4.1, I don't think we should support any 3.x Engine - otherwise we
>> will have to waste time maintaining old apis and infrastructure, instead
>> of adding new features that matter to our users.
>
> Do you have a list of old APIs you'd like to throw away? We've killed a
> few in 4.0, and
> $ git grep REQUIRED_FOR
> is not huge.
I don't think we have many verbs to remove, it is mainly about rotten
infrastructure that we can delete or simplify.
Nir
>
>>
>> I suggest we disable now support for 3.x engines.
>>
>> Please see Eli patch:
>> https://gerrit.ovirt.org/59308
>>
>> Thoughts?
>
> +1, but let's see if ydary/mgoldboi think we should keep 3.6.
2868
days inactive
2870
days old
11 comments
7 participants
participants (7)
-
Dan Kenigsberg -
Michal Skrivanek -
Moran Goldboim -
Nir Soffer -
Sandro Bonazzola -
Yaniv Dary -
Yaniv Kaul