----- 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()

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

Reply via email to