----- Original Message -----
> From: "Dan Kenigsberg" <dan...@redhat.com>
> To: "VDSM Project Development" <vdsm-devel@lists.fedorahosted.org>,
> dc...@redhat.com
> Sent: Monday, October 7, 2013 5:25:22 PM
> Subject: [vdsm] vdsm sync meeting - October 7th 2013
>
> We had an unpleasant talk, hampered by statics and disconnection on
> danken's side. Beyond the noises I've managed to recognize Yaniv, Toni,
> Douglas, Danken, Ayal, Timothy, Yeela and Mooli. We've managed to discuss:
>
> - vdsm-4.13.0 is tagged, with a know selinux issue on el6. Expect a new
> seliux-policy solving it any time soon.
>
> - All bugfixes should be backported to ovirt-3.3, so that we have a
> stable and comfortable vdsm in ovirt-3.3.1. Risky changes and new
> features should remain in master IMO.
>
> - We incorporated a glusterfs requirement breaking rpm installaiton for
> people. We should avoid that by posters notifying reviewers more
> prominently and by having
> http://jenkins.ovirt.org/job/vdsm_install_rpm_sanity_gerrit/
> run on every patch that touches vdsm.spec.in.
>
> David, could you make the adjustment to the job?
>
> - We discussed feature negotiation: Toni and Dan liked the idea of
> having vdsm expose a feature flags, to make it easier on Engine to
> check if a certain feature is supported.
>
> Ayal argues that this is useful only for capabilities that depend on
> existence on lower level components. Sees little value in fine
> feature granularity on vdsm side - versions is enough.
>
> So the disputed question is only how many feature flags we should
> have, and when to set them: statically or based on negotiation with
> kernel/libvirt/gluster/what not.
I already voiced my reservation over the entire concept
of "feature flags".
Proposing we only move to specific introspective verbs
maintained in the subsystem.
Have vdsm.getAvailableStorageDomainTypes() ['gluster']
instead of vdsm.getFeatures()
['storagetype/gluster']
It allows for much higher level of flexibility as the aforementioned verb
can also return other information about the domain type:
For example returning each domain type with parameter information:
{'nfs': {'connect_params': [
{'name': 'timeout',
'type': 'int',
'range': [0, 99],
'desc': 'Sets the timeout',
So even parameters can potentially be introspected.
>
> - Unified network persistence patches are being merged into master
>
> - Timothy is working on fixing
> http://jenkins.ovirt.org/job/vdsm_verify_error_codes/lastBuild/console
> (hopefully by introducing the new error codes to Engine)
>
> I was dropped from the call, so please append with stuff that I've
> missed. Sorry for the noise!
>
> Dan.
> _______________________________________________
> vdsm-devel mailing list
> vdsm-devel@lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
>
_______________________________________________
vdsm-devel mailing list
vdsm-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
