Ending support for 3.x engines on master
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
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.
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@redhat.com IRC : ydary On Sun, Jun 19, 2016 at 3:40 PM, Dan Kenigsberg <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.
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.
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@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@redhat.com IRC : ydary
On Sun, Jun 19, 2016 at 3:40 PM, Dan Kenigsberg <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.
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.
--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@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@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@redhat.com <mailto:ydary@redhat.com> IRC : ydary =20 On Sun, Jun 19, 2016 at 3:40 PM, Dan Kenigsberg <danken@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@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@redhat.com</a>>= 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@redhat.com</a>></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@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@redhat.com</a>></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@ovirt.org</a><br = class=3D"">http://lists.ovirt.org/mailman/listinfo/devel</div></blockquote=
</div><br class=3D""></body></html>=
--Apple-Mail=_F7420601-C321-4F16-BEEE-0C3903603AB0--
On Sun, Jun 19, 2016 at 3:06 PM, Moran Goldboim <mgoldboi@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@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@redhat.com IRC : ydary
On Sun, Jun 19, 2016 at 3:40 PM, Dan Kenigsberg <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.
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@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
On Tue, Jun 21, 2016 at 9:39 AM, Sandro Bonazzola <sbonazzo@redhat.com> wrote:
On Sun, Jun 19, 2016 at 3:06 PM, Moran Goldboim <mgoldboi@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@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@redhat.com IRC : ydary
On Sun, Jun 19, 2016 at 3:40 PM, Dan Kenigsberg <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.
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@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
On Tue, Jun 21, 2016 at 10:05 AM, Moran Goldboim <mgoldboi@redhat.com> wrote:
On Tue, Jun 21, 2016 at 9:39 AM, Sandro Bonazzola <sbonazzo@redhat.com> wrote:
On Sun, Jun 19, 2016 at 3:06 PM, Moran Goldboim <mgoldboi@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@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@redhat.com IRC : ydary
On Sun, Jun 19, 2016 at 3:40 PM, Dan Kenigsberg <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.
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@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@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
On Tue, Jun 21, 2016 at 11:20 AM, Yaniv Kaul <ykaul@redhat.com> wrote:
On Tue, Jun 21, 2016 at 10:05 AM, Moran Goldboim <mgoldboi@redhat.com> wrote:
On Tue, Jun 21, 2016 at 9:39 AM, Sandro Bonazzola <sbonazzo@redhat.com> wrote:
On Sun, Jun 19, 2016 at 3:06 PM, Moran Goldboim <mgoldboi@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@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@redhat.com IRC : ydary
On Sun, Jun 19, 2016 at 3:40 PM, Dan Kenigsberg <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.
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@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@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
On Sun, Jun 19, 2016 at 4:00 PM, Yaniv Dary <ydary@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@redhat.com IRC : ydary
On Sun, Jun 19, 2016 at 3:40 PM, Dan Kenigsberg <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.
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.
On Sun, Jun 19, 2016 at 3:40 PM, Dan Kenigsberg <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.
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.
On Mon, Jun 20, 2016 at 7:49 PM, Nir Soffer <nsoffer@redhat.com> wrote:
On Sun, Jun 19, 2016 at 3:40 PM, Dan Kenigsberg <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.
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.
participants (7)
-
Dan Kenigsberg -
Michal Skrivanek -
Moran Goldboim -
Nir Soffer -
Sandro Bonazzola -
Yaniv Dary -
Yaniv Kaul