Re: [vdsm] vdsm sync meeting - October 7th 2013

2013-10-07 Thread Saggi Mizrahi


- Original Message -
> From: "Dan Kenigsberg" 
> To: "VDSM Project Development" , 
> 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


[vdsm] vdsm sync meeting - October 7th 2013

2013-10-07 Thread Dan Kenigsberg
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.

- 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