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(a)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(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel