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 ;)
_______________________________________________
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel
