----- Original Message ----- > From: "Saggi Mizrahi" <[email protected]> > To: "Oved Ourfalli" <[email protected]> > Cc: [email protected], "VDSM Project Development" > <[email protected]> > Sent: Tuesday, October 8, 2013 4:08:12 PM > Subject: Re: [vdsm] vdsm sync meeting - October 7th 2013 > > > > ----- Original Message ----- > > From: "Oved Ourfalli" <[email protected]> > > To: "Saggi Mizrahi" <[email protected]> > > Cc: "Dan Kenigsberg" <[email protected]>, [email protected], "VDSM Project > > Development" > > <[email protected]> > > Sent: Tuesday, October 8, 2013 11:42:23 AM > > Subject: Re: [vdsm] vdsm sync meeting - October 7th 2013 > > > > > > > > ----- Original Message ----- > > > From: "Saggi Mizrahi" <[email protected]> > > > To: "Dan Kenigsberg" <[email protected]> > > > Cc: [email protected], "VDSM Project Development" > > > <[email protected]> > > > Sent: Monday, October 7, 2013 5:42:54 PM > > > Subject: Re: [vdsm] vdsm sync meeting - October 7th 2013 > > > > > > > > > > > > ----- Original Message ----- > > > > From: "Dan Kenigsberg" <[email protected]> > > > > To: "VDSM Project Development" <[email protected]>, > > > > [email protected] > > > > 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 > > > > [email protected] > > > > https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel > > > > > > > _______________________________________________ > > > vdsm-devel mailing list > > > [email protected] > > > https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel > > > > > > _______________________________________________ > vdsm-devel mailing list > [email protected] > https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel > _______________________________________________ vdsm-devel mailing list [email protected] https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
