Re: [vdsm] vdsm sync meeting - October 7th 2013
On Wed, Oct 09, 2013 at 08:27:58AM -0400, Mike Burns wrote: > On 10/08/2013 04:52 PM, Douglas Schilling Landgraf wrote: > >On 10/08/2013 05:08 AM, Dan Kenigsberg wrote: > >>On Mon, Oct 07, 2013 at 03:25:22PM +0100, Dan Kenigsberg wrote: > >>>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: > >> > >>I've forgot to mention the resolution of > >> > >> Bug 1007980 - Failed to run VM with gluster drives: internal error > >> unexpected address type for ide disk > >> > >>by http://gerrit.ovirt.org/19949 . Due to its being a serious painpoint > >>to users. I've backport this fix to both ovirt-3.3 and ovirt-3.3.0 > >>branches. > >> > >>Douglas, would you issue a Fedora build from the ovirt-3.3.0 branch? I > >>think this deserves an async build and an update of the ovirt-3.3 > >>reporsitory. > >> > > > >Sure. > > > >F19: http://koji.fedoraproject.org/koji/taskinfo?taskID=6037496 > >F20: http://koji.fedoraproject.org/koji/taskinfo?taskID=6037437 > >EL6: http://koji.fedoraproject.org/koji/taskinfo?taskID=6037527 > > > >Changes included into vdsm 4.12.1-3: > >- vm.Vm._getUnderlyingDriveInfo: extract path of gluster disks (BZ#1007980) > >- Require libvirt that allows vmUpdateDevice (BZ#1001001) > >- imageSharing: return proper size in httpGetSize > >- vdsmd.init: Add service-is-managed in shutdown_conflicting_srv > >(BZ#1006842) > > > >Adding in CC mburns for ovirt.org stuff. > > > > > Builds posted to ovirt.org updates-testing repo. They'll be pushed > live with 3.3.0.1 release Thanks! ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] vdsm sync meeting - October 7th 2013
On 10/08/2013 04:52 PM, Douglas Schilling Landgraf wrote: On 10/08/2013 05:08 AM, Dan Kenigsberg wrote: On Mon, Oct 07, 2013 at 03:25:22PM +0100, Dan Kenigsberg wrote: 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: I've forgot to mention the resolution of Bug 1007980 - Failed to run VM with gluster drives: internal error unexpected address type for ide disk by http://gerrit.ovirt.org/19949 . Due to its being a serious painpoint to users. I've backport this fix to both ovirt-3.3 and ovirt-3.3.0 branches. Douglas, would you issue a Fedora build from the ovirt-3.3.0 branch? I think this deserves an async build and an update of the ovirt-3.3 reporsitory. Sure. F19: http://koji.fedoraproject.org/koji/taskinfo?taskID=6037496 F20: http://koji.fedoraproject.org/koji/taskinfo?taskID=6037437 EL6: http://koji.fedoraproject.org/koji/taskinfo?taskID=6037527 Changes included into vdsm 4.12.1-3: - vm.Vm._getUnderlyingDriveInfo: extract path of gluster disks (BZ#1007980) - Require libvirt that allows vmUpdateDevice (BZ#1001001) - imageSharing: return proper size in httpGetSize - vdsmd.init: Add service-is-managed in shutdown_conflicting_srv (BZ#1006842) Adding in CC mburns for ovirt.org stuff. Builds posted to ovirt.org updates-testing repo. They'll be pushed live with 3.3.0.1 release Mike ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] vdsm sync meeting - October 7th 2013
On 10/08/2013 05:08 AM, Dan Kenigsberg wrote: On Mon, Oct 07, 2013 at 03:25:22PM +0100, Dan Kenigsberg wrote: 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: I've forgot to mention the resolution of Bug 1007980 - Failed to run VM with gluster drives: internal error unexpected address type for ide disk by http://gerrit.ovirt.org/19949 . Due to its being a serious painpoint to users. I've backport this fix to both ovirt-3.3 and ovirt-3.3.0 branches. Douglas, would you issue a Fedora build from the ovirt-3.3.0 branch? I think this deserves an async build and an update of the ovirt-3.3 reporsitory. Sure. F19: http://koji.fedoraproject.org/koji/taskinfo?taskID=6037496 F20: http://koji.fedoraproject.org/koji/taskinfo?taskID=6037437 EL6: http://koji.fedoraproject.org/koji/taskinfo?taskID=6037527 Changes included into vdsm 4.12.1-3: - vm.Vm._getUnderlyingDriveInfo: extract path of gluster disks (BZ#1007980) - Require libvirt that allows vmUpdateDevice (BZ#1001001) - imageSharing: return proper size in httpGetSize - vdsmd.init: Add service-is-managed in shutdown_conflicting_srv (BZ#1006842) Adding in CC mburns for ovirt.org stuff. -- Cheers Douglas ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] vdsm sync meeting - October 7th 2013
- Original Message - > From: "Oved Ourfalli" > To: "Saggi Mizrahi" > Cc: dc...@redhat.com, "VDSM Project Development" > > Sent: Tuesday, October 8, 2013 4:15:22 PM > Subject: Re: [vdsm] vdsm sync meeting - October 7th 2013 > > > > - Original Message - > > From: "Saggi Mizrahi" > > To: "Oved Ourfalli" > > Cc: dc...@redhat.com, "VDSM Project Development" > > > > Sent: Tuesday, October 8, 2013 4:08:12 PM > > Subject: Re: [vdsm] vdsm sync meeting - October 7th 2013 > > > > > > > > - Original Message - > > > From: "Oved Ourfalli" > > > To: "Saggi Mizrahi" > > > Cc: "Dan Kenigsberg" , dc...@redhat.com, "VDSM Project > > > Development" > > > > > > Sent: Tuesday, October 8, 2013 11:42:23 AM > > > Subject: Re: [vdsm] vdsm sync meeting - October 7th 2013 > > > > > > > > > > > > - Original Message - > > > > From: "Saggi Mizrahi" > > > > To: "Dan Kenigsberg" > > > > Cc: dc...@redhat.com, "VDSM Project Development" > > > > > > > > Sent: Monday, October 7, 2013 5:42:54 PM > > > > Subject: Re: [vdsm] vdsm sync meeting - October 7th 2013 > > > > > > > > > > > > > > > > - 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. > > > > > > > > > > > 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'] > > > > &
Re: [vdsm] vdsm sync meeting - October 7th 2013
- Original Message -
> From: "Saggi Mizrahi"
> To: "Oved Ourfalli"
> Cc: dc...@redhat.com, "VDSM Project Development"
>
> Sent: Tuesday, October 8, 2013 4:08:12 PM
> Subject: Re: [vdsm] vdsm sync meeting - October 7th 2013
>
>
>
> - Original Message -
> > From: "Oved Ourfalli"
> > To: "Saggi Mizrahi"
> > Cc: "Dan Kenigsberg" , dc...@redhat.com, "VDSM Project
> > Development"
> >
> > Sent: Tuesday, October 8, 2013 11:42:23 AM
> > Subject: Re: [vdsm] vdsm sync meeting - October 7th 2013
> >
> >
> >
> > - Original Message -
> > > From: "Saggi Mizrahi"
> > > To: "Dan Kenigsberg"
> > > Cc: dc...@redhat.com, "VDSM Project Development"
> > >
> > > Sent: Monday, October 7, 2013 5:42:54 PM
> > > Subject: Re: [vdsm] vdsm sync meeting - October 7th 2013
> > >
> > >
> > >
> > > - 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.
> > > >
> >
> > 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
Re: [vdsm] vdsm sync meeting - October 7th 2013
- Original Message -
> From: "Oved Ourfalli"
> To: "Saggi Mizrahi"
> Cc: "Dan Kenigsberg" , dc...@redhat.com, "VDSM Project
> Development"
>
> Sent: Tuesday, October 8, 2013 11:42:23 AM
> Subject: Re: [vdsm] vdsm sync meeting - October 7th 2013
>
>
>
> - Original Message -
> > From: "Saggi Mizrahi"
> > To: "Dan Kenigsberg"
> > Cc: dc...@redhat.com, "VDSM Project Development"
> >
> > Sent: Monday, October 7, 2013 5:42:54 PM
> > Subject: Re: [vdsm] vdsm sync meeting - October 7th 2013
> >
> >
> >
> > - 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.
> > >
>
> 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.
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 wi
Re: [vdsm] vdsm sync meeting - October 7th 2013
On Mon, Oct 07, 2013 at 03:25:22PM +0100, Dan Kenigsberg wrote: > 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: I've forgot to mention the resolution of Bug 1007980 - Failed to run VM with gluster drives: internal error unexpected address type for ide disk by http://gerrit.ovirt.org/19949 . Due to its being a serious painpoint to users. I've backport this fix to both ovirt-3.3 and ovirt-3.3.0 branches. Douglas, would you issue a Fedora build from the ovirt-3.3.0 branch? I think this deserves an async build and an update of the ovirt-3.3 reporsitory. Dan. ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] vdsm sync meeting - October 7th 2013
- Original Message -
> From: "Saggi Mizrahi"
> To: "Dan Kenigsberg"
> Cc: dc...@redhat.com, "VDSM Project Development"
>
> Sent: Monday, October 7, 2013 5:42:54 PM
> Subject: Re: [vdsm] vdsm sync meeting - October 7th 2013
>
>
>
> - 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.
> >
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. 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
Re: [vdsm] vdsm sync meeting - October 7th 2013
- 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
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
