Current master branch of vdsm (destined for our 3.6 release) uses el7 as its main platform. New features are expected to be available only on el7 (and modern Fedoras) but not on el6. On el6, vdsm still builds, runs, and exports clusterLevel <= 3.5, with no feature loss relative to 3.5. This has been done per gluster request. However, maintaining this furhter as high costs: we keep testing el6, we need to make sure nothing breaks there, and there's a lot of legacy code that we could start deleting. Sahina, would you explain (again... sorry for not recalling the details) why ovirt-3.6's vdsm should keep running on el6? I'd like to see if there's a nother means to solve the underlying gluster issue. Regards, Dan.
On 03/16/2015 03:28 PM, Dan Kenigsberg wrote:
Current master branch of vdsm (destined for our 3.6 release) uses el7 as its main platform. New features are expected to be available only on el7 (and modern Fedoras) but not on el6.
On el6, vdsm still builds, runs, and exports clusterLevel <= 3.5, with no feature loss relative to 3.5. This has been done per gluster request.
However, maintaining this furhter as high costs: we keep testing el6, we need to make sure nothing breaks there, and there's a lot of legacy code that we could start deleting.
Sahina, would you explain (again... sorry for not recalling the details) why ovirt-3.6's vdsm should keep running on el6? I'd like to see if there's a nother means to solve the underlying gluster issue.
This was only because downstream gluster + vdsm would continue to be supported on RHEL 6.
Regards, Dan.
On 03/16/2015 06:02 PM, Sahina Bose wrote:
On 03/16/2015 03:28 PM, Dan Kenigsberg wrote:
Current master branch of vdsm (destined for our 3.6 release) uses el7 as its main platform. New features are expected to be available only on el7 (and modern Fedoras) but not on el6.
On el6, vdsm still builds, runs, and exports clusterLevel <= 3.5, with no feature loss relative to 3.5. This has been done per gluster request.
However, maintaining this furhter as high costs: we keep testing el6, we need to make sure nothing breaks there, and there's a lot of legacy code that we could start deleting.
Sahina, would you explain (again... sorry for not recalling the details) why ovirt-3.6's vdsm should keep running on el6? I'd like to see if there's a nother means to solve the underlying gluster issue.
This was only because downstream gluster + vdsm would continue to be supported on RHEL 6.
is there an expected date at which new features would be .el7 only, so .el6 support can be dropped upstream?
Regards, Dan.
_______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
----- Original Message -----
From: "Itamar Heim" <iheim@redhat.com> To: "Sahina Bose" <sabose@redhat.com>, "Dan Kenigsberg" <danken@redhat.com>, devel@ovirt.org Sent: Monday, March 16, 2015 11:41:36 PM Subject: Re: [ovirt-devel] el6 future in ovirt-3.6
On 03/16/2015 06:02 PM, Sahina Bose wrote:
On 03/16/2015 03:28 PM, Dan Kenigsberg wrote:
Current master branch of vdsm (destined for our 3.6 release) uses el7 as its main platform. New features are expected to be available only on el7 (and modern Fedoras) but not on el6.
On el6, vdsm still builds, runs, and exports clusterLevel <= 3.5, with no feature loss relative to 3.5. This has been done per gluster request.
However, maintaining this furhter as high costs: we keep testing el6, we need to make sure nothing breaks there, and there's a lot of legacy code that we could start deleting.
Sahina, would you explain (again... sorry for not recalling the details) why ovirt-3.6's vdsm should keep running on el6? I'd like to see if there's a nother means to solve the underlying gluster issue.
This was only because downstream gluster + vdsm would continue to be supported on RHEL 6.
is there an expected date at which new features would be .el7 only, so .el6 support can be dropped upstream?
there is no reason to drop anything from upstream if it is to be supported. it will only create overhead for product support. we have long on going effort is to reduce diff while you keep pushing for fork. it always turned out to be incorrect decision. please learn from experience.
Regards, Dan.
_______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
_______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
On 03/16/2015 11:48 PM, Alon Bar-Lev wrote:
----- Original Message -----
From: "Itamar Heim" <iheim@redhat.com> To: "Sahina Bose" <sabose@redhat.com>, "Dan Kenigsberg" <danken@redhat.com>, devel@ovirt.org Sent: Monday, March 16, 2015 11:41:36 PM Subject: Re: [ovirt-devel] el6 future in ovirt-3.6
On 03/16/2015 06:02 PM, Sahina Bose wrote:
On 03/16/2015 03:28 PM, Dan Kenigsberg wrote:
Current master branch of vdsm (destined for our 3.6 release) uses el7 as its main platform. New features are expected to be available only on el7 (and modern Fedoras) but not on el6.
On el6, vdsm still builds, runs, and exports clusterLevel <= 3.5, with no feature loss relative to 3.5. This has been done per gluster request.
However, maintaining this furhter as high costs: we keep testing el6, we need to make sure nothing breaks there, and there's a lot of legacy code that we could start deleting.
Sahina, would you explain (again... sorry for not recalling the details) why ovirt-3.6's vdsm should keep running on el6? I'd like to see if there's a nother means to solve the underlying gluster issue.
This was only because downstream gluster + vdsm would continue to be supported on RHEL 6.
is there an expected date at which new features would be .el7 only, so .el6 support can be dropped upstream?
there is no reason to drop anything from upstream if it is to be supported. it will only create overhead for product support. we have long on going effort is to reduce diff while you keep pushing for fork. it always turned out to be incorrect decision. please learn from experience.
I asked when they plan to drop support, so we can drop unneeded code.
Regards, Dan.
_______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
_______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
----- Original Message -----
From: "Itamar Heim" <iheim@redhat.com> To: "Alon Bar-Lev" <alonbl@redhat.com> Cc: "Sahina Bose" <sabose@redhat.com>, "Dan Kenigsberg" <danken@redhat.com>, devel@ovirt.org Sent: Monday, March 16, 2015 11:55:05 PM Subject: Re: [ovirt-devel] el6 future in ovirt-3.6
On 03/16/2015 11:48 PM, Alon Bar-Lev wrote:
----- Original Message -----
From: "Itamar Heim" <iheim@redhat.com> To: "Sahina Bose" <sabose@redhat.com>, "Dan Kenigsberg" <danken@redhat.com>, devel@ovirt.org Sent: Monday, March 16, 2015 11:41:36 PM Subject: Re: [ovirt-devel] el6 future in ovirt-3.6
On 03/16/2015 06:02 PM, Sahina Bose wrote:
On 03/16/2015 03:28 PM, Dan Kenigsberg wrote:
Current master branch of vdsm (destined for our 3.6 release) uses el7 as its main platform. New features are expected to be available only on el7 (and modern Fedoras) but not on el6.
On el6, vdsm still builds, runs, and exports clusterLevel <= 3.5, with no feature loss relative to 3.5. This has been done per gluster request.
However, maintaining this furhter as high costs: we keep testing el6, we need to make sure nothing breaks there, and there's a lot of legacy code that we could start deleting.
Sahina, would you explain (again... sorry for not recalling the details) why ovirt-3.6's vdsm should keep running on el6? I'd like to see if there's a nother means to solve the underlying gluster issue.
This was only because downstream gluster + vdsm would continue to be supported on RHEL 6.
is there an expected date at which new features would be .el7 only, so .el6 support can be dropped upstream?
there is no reason to drop anything from upstream if it is to be supported. it will only create overhead for product support. we have long on going effort is to reduce diff while you keep pushing for fork. it always turned out to be incorrect decision. please learn from experience.
I asked when they plan to drop support, so we can drop unneeded code.
I do not understand. unneeded code from where? you wrote "upstream" which suggest you keep it "downstream". Had you written from "product" / "vdsm" I would not have responded. vdsm master (aka 3.6) should work or should not work on el6? [downstream/upstream/customized] does it mean that 3.6 cluster level will not be supported at el6? does it mean that 3.5 will be supported long cycle for el6 to bridge the gap for these who do not upgrade to el7? no new features for el6 (z-stream only)?
Regards, Dan.
_______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
_______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
On 03/17/2015 12:01 AM, Alon Bar-Lev wrote:
----- Original Message -----
From: "Itamar Heim" <iheim@redhat.com> To: "Alon Bar-Lev" <alonbl@redhat.com> Cc: "Sahina Bose" <sabose@redhat.com>, "Dan Kenigsberg" <danken@redhat.com>, devel@ovirt.org Sent: Monday, March 16, 2015 11:55:05 PM Subject: Re: [ovirt-devel] el6 future in ovirt-3.6
On 03/16/2015 11:48 PM, Alon Bar-Lev wrote:
----- Original Message -----
From: "Itamar Heim" <iheim@redhat.com> To: "Sahina Bose" <sabose@redhat.com>, "Dan Kenigsberg" <danken@redhat.com>, devel@ovirt.org Sent: Monday, March 16, 2015 11:41:36 PM Subject: Re: [ovirt-devel] el6 future in ovirt-3.6
On 03/16/2015 06:02 PM, Sahina Bose wrote:
On 03/16/2015 03:28 PM, Dan Kenigsberg wrote:
Current master branch of vdsm (destined for our 3.6 release) uses el7 as its main platform. New features are expected to be available only on el7 (and modern Fedoras) but not on el6.
On el6, vdsm still builds, runs, and exports clusterLevel <= 3.5, with no feature loss relative to 3.5. This has been done per gluster request.
However, maintaining this furhter as high costs: we keep testing el6, we need to make sure nothing breaks there, and there's a lot of legacy code that we could start deleting.
Sahina, would you explain (again... sorry for not recalling the details) why ovirt-3.6's vdsm should keep running on el6? I'd like to see if there's a nother means to solve the underlying gluster issue.
This was only because downstream gluster + vdsm would continue to be supported on RHEL 6.
is there an expected date at which new features would be .el7 only, so .el6 support can be dropped upstream?
there is no reason to drop anything from upstream if it is to be supported. it will only create overhead for product support. we have long on going effort is to reduce diff while you keep pushing for fork. it always turned out to be incorrect decision. please learn from experience.
I asked when they plan to drop support, so we can drop unneeded code.
I do not understand. unneeded code from where? you wrote "upstream" which suggest you keep it "downstream". Had you written from "product" / "vdsm" I would not have responded.
vdsm master (aka 3.6) should work or should not work on el6? [downstream/upstream/customized]
should work, for gluster
does it mean that 3.6 cluster level will not be supported at el6?
for virt side, yes.
does it mean that 3.5 will be supported long cycle for el6 to bridge the gap for these who do not upgrade to el7? no new features for el6 (z-stream only)?
yes, that's the plan - no new features for the virt side for .el6. my question was when this would be true for the gluster side.
Regards, Dan.
_______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
_______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
----- Original Message -----
From: "Itamar Heim" <iheim@redhat.com> To: "Alon Bar-Lev" <alonbl@redhat.com> Cc: "Sahina Bose" <sabose@redhat.com>, "Dan Kenigsberg" <danken@redhat.com>, devel@ovirt.org Sent: Tuesday, March 17, 2015 12:10:46 AM Subject: Re: [ovirt-devel] el6 future in ovirt-3.6
On 03/17/2015 12:01 AM, Alon Bar-Lev wrote:
----- Original Message -----
From: "Itamar Heim" <iheim@redhat.com> To: "Alon Bar-Lev" <alonbl@redhat.com> Cc: "Sahina Bose" <sabose@redhat.com>, "Dan Kenigsberg" <danken@redhat.com>, devel@ovirt.org Sent: Monday, March 16, 2015 11:55:05 PM Subject: Re: [ovirt-devel] el6 future in ovirt-3.6
On 03/16/2015 11:48 PM, Alon Bar-Lev wrote:
----- Original Message -----
From: "Itamar Heim" <iheim@redhat.com> To: "Sahina Bose" <sabose@redhat.com>, "Dan Kenigsberg" <danken@redhat.com>, devel@ovirt.org Sent: Monday, March 16, 2015 11:41:36 PM Subject: Re: [ovirt-devel] el6 future in ovirt-3.6
On 03/16/2015 06:02 PM, Sahina Bose wrote:
On 03/16/2015 03:28 PM, Dan Kenigsberg wrote: > Current master branch of vdsm (destined for our 3.6 release) uses el7 > as > its main platform. New features are expected to be available only on > el7 > (and modern Fedoras) but not on el6. > > On el6, vdsm still builds, runs, and exports clusterLevel <= 3.5, with > no feature loss relative to 3.5. This has been done per gluster > request. > > However, maintaining this furhter as high costs: we keep testing el6, > we > need to make sure nothing breaks there, and there's a lot of legacy > code > that we could start deleting. > > Sahina, would you explain (again... sorry for not recalling the > details) > why ovirt-3.6's vdsm should keep running on el6? I'd like to see if > there's a nother means to solve the underlying gluster issue.
This was only because downstream gluster + vdsm would continue to be supported on RHEL 6.
is there an expected date at which new features would be .el7 only, so .el6 support can be dropped upstream?
there is no reason to drop anything from upstream if it is to be supported. it will only create overhead for product support. we have long on going effort is to reduce diff while you keep pushing for fork. it always turned out to be incorrect decision. please learn from experience.
I asked when they plan to drop support, so we can drop unneeded code.
I do not understand. unneeded code from where? you wrote "upstream" which suggest you keep it "downstream". Had you written from "product" / "vdsm" I would not have responded.
vdsm master (aka 3.6) should work or should not work on el6? [downstream/upstream/customized]
should work, for gluster
does it mean that 3.6 cluster level will not be supported at el6?
for virt side, yes.
does it mean that 3.5 will be supported long cycle for el6 to bridge the gap for these who do not upgrade to el7? no new features for el6 (z-stream only)?
yes, that's the plan - no new features for the virt side for .el6. my question was when this would be true for the gluster side.
I cannot understand these conflicting statements. if any component of vdsm needs to run on el6, el6 support cannot be dropped, this [among other] includes python version and other infra modules, packaging included. a possible sensible solution is to continue maintaining 3.5 for gluster on el6 with possibly new features, and have master free of el6 for all dependencies. dropping el6 from 3.6 should have been early in development cycle to allow proper testing. the gluster issue should have resolved even before the 3.6 cycle.
> > Regards, > Dan.
_______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
_______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
+1 also take a look at the results of the user survey: most users use el6 so even the discussion about "dropping support" will make people uncertain how long they will be able to use el6. me included. On 16/03/15 23:19, Alon Bar-Lev wrote:
I cannot understand these conflicting statements.
if any component of vdsm needs to run on el6, el6 support cannot be dropped, this [among other] includes python version and other infra modules, packaging included.
a possible sensible solution is to continue maintaining 3.5 for gluster on el6 with possibly new features, and have master free of el6 for all dependencies.
dropping el6 from 3.6 should have been early in development cycle to allow proper testing. the gluster issue should have resolved even before the 3.6 cycle.
-- Mit freundlichen Grüßen / Regards Sven Kieske Systemadministrator Mittwald CM Service GmbH & Co. KG Königsberger Straße 6 32339 Espelkamp T: +49-5772-293-100 F: +49-5772-293-333 https://www.mittwald.de Geschäftsführer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen
On Mar 17, 2015, at 09:47 , Sven Kieske <S.Kieske@mittwald.de> wrote:
+1
also take a look at the results of the user survey: most users use el6 so even the discussion about "dropping support" will make people uncertain how long they will be able to use el6. me included.
well, of course most users use el6, that's the only stable platform we had till very recently. Most of the 3.6 features require el7, so new features can only be added there. 3.5 will be maintained for as long is needed/requested, but eventually we have to move on. After all, hypervisor hosts are supposed to be in full control of oVirt so you shouldn't care/modify them too much. We always support only the recent minor releases, so in this sense we did drop <=6.5 in 3.5 already; you can only run on 6.6, 7.0 and 7.1. Thanks, michal
On 16/03/15 23:19, Alon Bar-Lev wrote:
I cannot understand these conflicting statements.
if any component of vdsm needs to run on el6, el6 support cannot be dropped, this [among other] includes python version and other infra modules, packaging included.
a possible sensible solution is to continue maintaining 3.5 for gluster on el6 with possibly new features, and have master free of el6 for all dependencies.
dropping el6 from 3.6 should have been early in development cycle to allow proper testing. the gluster issue should have resolved even before the 3.6 cycle.
-- Mit freundlichen Grüßen / Regards
Sven Kieske
Systemadministrator Mittwald CM Service GmbH & Co. KG Königsberger Straße 6 32339 Espelkamp T: +49-5772-293-100 F: +49-5772-293-333 https://www.mittwald.de Geschäftsführer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen _______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
On Tue, Mar 17, 2015 at 09:47:17AM +0100, Sven Kieske wrote:
+1
also take a look at the results of the user survey: most users use el6 so even the discussion about "dropping support" will make people uncertain how long they will be able to use el6. me included.
Given the recent discussions, this seems the way we are going to take: ovirt-3.5 would keep support of el6 as long as it (ovirt-3.5) is maintained. ovirt-3.6 (current master) would no longer support el6 for the hypervisor. Vdsm would not be tested on el6, it won't build there, and most probably not run properly/at all on el6. If someone thinks that this is a wrong step to take - say so now, or be silent forever. Dan.
On 03/23/2015 10:19 AM, Dan Kenigsberg wrote:
On Tue, Mar 17, 2015 at 09:47:17AM +0100, Sven Kieske wrote:
+1
also take a look at the results of the user survey: most users use el6 so even the discussion about "dropping support" will make people uncertain how long they will be able to use el6. me included.
Given the recent discussions, this seems the way we are going to take: ovirt-3.5 would keep support of el6 as long as it (ovirt-3.5) is maintained.
ovirt-3.6 (current master) would no longer support el6 for the hypervisor. Vdsm would not be tested on el6, it won't build there, and most probably not run properly/at all on el6.
ovirt-3.6 engine would still support .el6 hosts with vdsm 3.5. we will simply not release the new vdsm to the .el6 channel.
If someone thinks that this is a wrong step to take - say so now, or be silent forever.
Dan. _______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Il 25/03/2015 11:38, Itamar Heim ha scritto:
On 03/23/2015 10:19 AM, Dan Kenigsberg wrote:
On Tue, Mar 17, 2015 at 09:47:17AM +0100, Sven Kieske wrote:
+1
also take a look at the results of the user survey: most users use el6 so even the discussion about "dropping support" will make people uncertain how long they will be able to use el6. me included.
Given the recent discussions, this seems the way we are going to take: ovirt-3.5 would keep support of el6 as long as it (ovirt-3.5) is maintained.
ovirt-3.6 (current master) would no longer support el6 for the hypervisor. Vdsm would not be tested on el6, it won't build there, and most probably not run properly/at all on el6.
ovirt-3.6 engine would still support .el6 hosts with vdsm 3.5. we will simply not release the new vdsm to the .el6 channel.
In this case, please fix the VDSM jobs running on master for dropping EL6. This will reduce the load on the slaves. Infra can assist with this if needed.
If someone thinks that this is a wrong step to take - say so now, or be silent forever.
Dan. _______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
_______________________________________________ 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 Mon, Mar 16, 2015 at 06:02:36PM +0200, Sahina Bose wrote:
On 03/16/2015 03:28 PM, Dan Kenigsberg wrote:
Current master branch of vdsm (destined for our 3.6 release) uses el7 as its main platform. New features are expected to be available only on el7 (and modern Fedoras) but not on el6.
On el6, vdsm still builds, runs, and exports clusterLevel <= 3.5, with no feature loss relative to 3.5. This has been done per gluster request.
However, maintaining this furhter as high costs: we keep testing el6, we need to make sure nothing breaks there, and there's a lot of legacy code that we could start deleting.
Sahina, would you explain (again... sorry for not recalling the details) why ovirt-3.6's vdsm should keep running on el6? I'd like to see if there's a nother means to solve the underlying gluster issue.
This was only because downstream gluster + vdsm would continue to be supported on RHEL 6.
Could you provide more details about your needs? Catering for d/s RHS is very important, but since it's expensive to maintain, I'd like to understand more. Please note again that when installed on el6, ovirt-3.6's vdsm would NOT expose clusterLevel=3.6, so theoretically you can keep ovirt-3.5's vdsm. Do you plan an Engine-side hack in order to use new 3.6 gluster functionality despite clusterLevel<=3.5? Regards, Dan.
On 03/17/2015 11:12 PM, Dan Kenigsberg wrote:
On Mon, Mar 16, 2015 at 06:02:36PM +0200, Sahina Bose wrote:
On 03/16/2015 03:28 PM, Dan Kenigsberg wrote:
Current master branch of vdsm (destined for our 3.6 release) uses el7 as its main platform. New features are expected to be available only on el7 (and modern Fedoras) but not on el6.
On el6, vdsm still builds, runs, and exports clusterLevel <= 3.5, with no feature loss relative to 3.5. This has been done per gluster request.
However, maintaining this furhter as high costs: we keep testing el6, we need to make sure nothing breaks there, and there's a lot of legacy code that we could start deleting.
Sahina, would you explain (again... sorry for not recalling the details) why ovirt-3.6's vdsm should keep running on el6? I'd like to see if there's a nother means to solve the underlying gluster issue. This was only because downstream gluster + vdsm would continue to be supported on RHEL 6. Could you provide more details about your needs? Catering for d/s RHS is very important, but since it's expensive to maintain, I'd like to understand more.
Please note again that when installed on el6, ovirt-3.6's vdsm would NOT expose clusterLevel=3.6, so theoretically you can keep ovirt-3.5's vdsm.
Do you plan an Engine-side hack in order to use new 3.6 gluster functionality despite clusterLevel<=3.5?
I wasn't aware that ovirt-3.6 would not expose clusterLevel 3.6 when installed on el6. Downstream RHS will need to be supported on both el6 and el7. And we have added some apis to vdsm master that we require for brick management, geo-rep management and gluster volume snapshot management. We have 2 options - fork off vdsm if it needs to move on to el7 support only in master. - backport to vdsm 3.5 (depending on what we decide on cluster level support for downstream)
Regards, Dan.
On Wed, Mar 18, 2015 at 09:39:45PM +0200, Sahina Bose wrote:
On 03/17/2015 11:12 PM, Dan Kenigsberg wrote:
On Mon, Mar 16, 2015 at 06:02:36PM +0200, Sahina Bose wrote:
On 03/16/2015 03:28 PM, Dan Kenigsberg wrote:
Current master branch of vdsm (destined for our 3.6 release) uses el7 as its main platform. New features are expected to be available only on el7 (and modern Fedoras) but not on el6.
On el6, vdsm still builds, runs, and exports clusterLevel <= 3.5, with no feature loss relative to 3.5. This has been done per gluster request.
However, maintaining this furhter as high costs: we keep testing el6, we need to make sure nothing breaks there, and there's a lot of legacy code that we could start deleting.
Sahina, would you explain (again... sorry for not recalling the details) why ovirt-3.6's vdsm should keep running on el6? I'd like to see if there's a nother means to solve the underlying gluster issue. This was only because downstream gluster + vdsm would continue to be supported on RHEL 6. Could you provide more details about your needs? Catering for d/s RHS is very important, but since it's expensive to maintain, I'd like to understand more.
Please note again that when installed on el6, ovirt-3.6's vdsm would NOT expose clusterLevel=3.6, so theoretically you can keep ovirt-3.5's vdsm.
Do you plan an Engine-side hack in order to use new 3.6 gluster functionality despite clusterLevel<=3.5?
I wasn't aware that ovirt-3.6 would not expose clusterLevel 3.6 when installed on el6. Downstream RHS will need to be supported on both el6 and el7. And we have added some apis to vdsm master that we require for brick management, geo-rep management and gluster volume snapshot management. We have 2 options - fork off vdsm if it needs to move on to el7 support only in master.
We (developers) WANT to shed off el7. But RHS is an important user; and there are other users that are simply happy to use el6 and don't want to desert it yet. We can keep el6 support even on 3.6 (with clusterLevel=3.5). The only problem (beside maintanence cost) is how gluster can tell these hosts apart. Can Engine manage a clusterLevel=3.5.5? Vdsm-3.6 can report it even on el6 hosts.
- backport to vdsm 3.5 (depending on what we decide on cluster level support for downstream)
I find it dangerous to introduce new features to a stable branch. It may introduce unwarrented instability to non-gluster users.
On 03/19/2015 01:05 AM, Dan Kenigsberg wrote:
On Wed, Mar 18, 2015 at 09:39:45PM +0200, Sahina Bose wrote:
On 03/17/2015 11:12 PM, Dan Kenigsberg wrote:
On Mon, Mar 16, 2015 at 06:02:36PM +0200, Sahina Bose wrote:
On 03/16/2015 03:28 PM, Dan Kenigsberg wrote:
Current master branch of vdsm (destined for our 3.6 release) uses el7 as its main platform. New features are expected to be available only on el7 (and modern Fedoras) but not on el6.
On el6, vdsm still builds, runs, and exports clusterLevel <= 3.5, with no feature loss relative to 3.5. This has been done per gluster request.
However, maintaining this furhter as high costs: we keep testing el6, we need to make sure nothing breaks there, and there's a lot of legacy code that we could start deleting.
Sahina, would you explain (again... sorry for not recalling the details) why ovirt-3.6's vdsm should keep running on el6? I'd like to see if there's a nother means to solve the underlying gluster issue. This was only because downstream gluster + vdsm would continue to be supported on RHEL 6. Could you provide more details about your needs? Catering for d/s RHS is very important, but since it's expensive to maintain, I'd like to understand more.
Please note again that when installed on el6, ovirt-3.6's vdsm would NOT expose clusterLevel=3.6, so theoretically you can keep ovirt-3.5's vdsm.
Do you plan an Engine-side hack in order to use new 3.6 gluster functionality despite clusterLevel<=3.5?
I wasn't aware that ovirt-3.6 would not expose clusterLevel 3.6 when installed on el6. Downstream RHS will need to be supported on both el6 and el7. And we have added some apis to vdsm master that we require for brick management, geo-rep management and gluster volume snapshot management. We have 2 options - fork off vdsm if it needs to move on to el7 support only in master.
We (developers) WANT to shed off el7. But RHS is an important user; and there are other users that are simply happy to use el6 and don't want to desert it yet.
We can keep el6 support even on 3.6 (with clusterLevel=3.5).
The only problem (beside maintanence cost) is how gluster can tell these hosts apart. Can Engine manage a clusterLevel=3.5.5? Vdsm-3.6 can report it even on el6 hosts.
- backport to vdsm 3.5 (depending on what we decide on cluster level support for downstream)
I find it dangerous to introduce new features to a stable branch. It may introduce unwarrented instability to non-gluster users. _______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
after discussing with Sahina, they will be able to handle upstream vdsm dropping .el6 support after a few weeks to adjust - say, April 1st ;)
On Mar 19, 2015, at 10:31 , Itamar Heim <iheim@redhat.com> wrote:
On 03/19/2015 01:05 AM, Dan Kenigsberg wrote:
On Wed, Mar 18, 2015 at 09:39:45PM +0200, Sahina Bose wrote:
On 03/17/2015 11:12 PM, Dan Kenigsberg wrote:
On Mon, Mar 16, 2015 at 06:02:36PM +0200, Sahina Bose wrote:
On 03/16/2015 03:28 PM, Dan Kenigsberg wrote:
Current master branch of vdsm (destined for our 3.6 release) uses el7 as its main platform. New features are expected to be available only on el7 (and modern Fedoras) but not on el6.
On el6, vdsm still builds, runs, and exports clusterLevel <= 3.5, with no feature loss relative to 3.5. This has been done per gluster request.
However, maintaining this furhter as high costs: we keep testing el6, we need to make sure nothing breaks there, and there's a lot of legacy code that we could start deleting.
Sahina, would you explain (again... sorry for not recalling the details) why ovirt-3.6's vdsm should keep running on el6? I'd like to see if there's a nother means to solve the underlying gluster issue. This was only because downstream gluster + vdsm would continue to be supported on RHEL 6. Could you provide more details about your needs? Catering for d/s RHS is very important, but since it's expensive to maintain, I'd like to understand more.
Please note again that when installed on el6, ovirt-3.6's vdsm would NOT expose clusterLevel=3.6, so theoretically you can keep ovirt-3.5's vdsm.
Do you plan an Engine-side hack in order to use new 3.6 gluster functionality despite clusterLevel<=3.5?
I wasn't aware that ovirt-3.6 would not expose clusterLevel 3.6 when installed on el6. Downstream RHS will need to be supported on both el6 and el7. And we have added some apis to vdsm master that we require for brick management, geo-rep management and gluster volume snapshot management. We have 2 options - fork off vdsm if it needs to move on to el7 support only in master.
We (developers) WANT to shed off el7. But RHS is an important user; and there are other users that are simply happy to use el6 and don't want to desert it yet.
We can keep el6 support even on 3.6 (with clusterLevel=3.5).
The only problem (beside maintanence cost) is how gluster can tell these hosts apart. Can Engine manage a clusterLevel=3.5.5? Vdsm-3.6 can report it even on el6 hosts.
- backport to vdsm 3.5 (depending on what we decide on cluster level support for downstream)
I find it dangerous to introduce new features to a stable branch. It may introduce unwarrented instability to non-gluster users. _______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
after discussing with Sahina, they will be able to handle upstream vdsm dropping .el6 support after a few weeks to adjust - say, April 1st ;)
so…dropping el6 from .spec April 2nd?:) And letting 3.6 features in, finally. I just want to avoid adding kludgy code to vdsm implementing different libvirt xml and behavior on el6/el7 Thanks, michal
_______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
participants (7)
-
Alon Bar-Lev -
Dan Kenigsberg -
Itamar Heim -
Michal Skrivanek -
Sahina Bose -
Sandro Bonazzola -
Sven Kieske