----- Original Message -----
> From: "Saggi Mizrahi" <smizr...@redhat.com>
> To: "Oved Ourfalli" <ov...@redhat.com>
> Cc: dc...@redhat.com, "VDSM Project Development" 
> <vdsm-devel@lists.fedorahosted.org>
> Sent: Tuesday, October 8, 2013 4:08:12 PM
> Subject: Re: [vdsm] vdsm sync meeting - October 7th 2013
> 
> 
> 
> ----- Original Message -----
> > From: "Oved Ourfalli" <ov...@redhat.com>
> > To: "Saggi Mizrahi" <smizr...@redhat.com>
> > Cc: "Dan Kenigsberg" <dan...@redhat.com>, dc...@redhat.com, "VDSM Project
> > Development"
> > <vdsm-devel@lists.fedorahosted.org>
> > Sent: Tuesday, October 8, 2013 11:42:23 AM
> > Subject: Re: [vdsm] vdsm sync meeting - October 7th 2013
> > 
> > 
> > 
> > ----- Original Message -----
> > > From: "Saggi Mizrahi" <smizr...@redhat.com>
> > > To: "Dan Kenigsberg" <dan...@redhat.com>
> > > Cc: dc...@redhat.com, "VDSM Project Development"
> > > <vdsm-devel@lists.fedorahosted.org>
> > > Sent: Monday, October 7, 2013 5:42:54 PM
> > > Subject: Re: [vdsm] vdsm sync meeting - October 7th 2013
> > > 
> > > 
> > > 
> > > ----- 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.
> > > > 
> > 
> > Versions might not be enough here, as some features might be supported by
> > VDSM version X, but not when it is installed under operating system Y.
> > IMO, VDSM should reflect that when reporting the features.
> > 
> > > >   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.
> > > 
> > 
> > IMO it is great to have a verb per "domain" (e.g. network, storage, virt,
> > etc.), as it allows getting deeper information about features.
> > However, it does not conflict with having a single general getFeatures
> > verb.
> > Such a verb can be useful cases in which you don't really need more
> > information, for example in establishing a feature negotiation between the
> > engine and VDSM.
> No one is talking about feature negotiation. It's feature reporting.

You're right. My bad. Feature reporting is the right terminology here.


> And all I'm saying is that having a verb reporting unrelated things in
> unrelated formats is usually a bad idea.
> 
> How would features be represented strings? fqdn? objects of different types?
> If it's a string how would the user know how features depends on each other.
> How granular should this be? How do we change granularity in the future?
> 
> We must have verbs with clear scope. Anyone can tell what
> GetServerConnectionTypes()
> needs to return. We know what it's granularity is. We know how it relates to
> other things. We know what flows need to check it and how it might effect
> them.
> 
> I have no idea what getFeatures() even means.
> 

The users don't have to directly look at the features the host returns.
The engine can have a mapping between features VDSM reports, and "user 
features" - features that do have a meaning to the user.
The mapping will probably be one-to-many in most cases.

> 
> > If you find out that a specific feature is supported, and
> > you would like to get more details, such as parameter information, you
> > would
> > query specifically for that.
> > 
> > > > 
> > > > - 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-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

Reply via email to