On Mar 19, 2015, at 10:31 , Itamar Heim <ih...@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 _______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel