----- Original Message ----- > From: "Dan Kenigsberg" <dan...@redhat.com> > To: "Doron Fediuck" <dfedi...@redhat.com> > Cc: engine-de...@ovirt.org, vdsm-de...@fedorahosted.org, "Genadi Chereshnya" > <gcher...@redhat.com> > Sent: Tuesday, October 23, 2012 1:41:03 PM > Subject: Re: [Engine-devel] [vdsm] unmanaged devices thrown into 'custom' > feature > > On Tue, Oct 23, 2012 at 05:53:20AM -0400, Doron Fediuck wrote: > > > > > > ----- Original Message ----- > > > From: "Livnat Peer" <lp...@redhat.com> > > > To: "Dan Kenigsberg" <dan...@redhat.com> > > > Cc: engine-de...@ovirt.org, "Genadi Chereshnya" > > > <gcher...@redhat.com>, vdsm-de...@fedorahosted.org > > > Sent: Monday, October 22, 2012 8:29:20 AM > > > Subject: Re: [Engine-devel] [vdsm] unmanaged devices thrown into > > > 'custom' feature > > > > > > On 21/10/12 23:49, Dan Kenigsberg wrote: > > > > On Sun, Oct 21, 2012 at 11:57:10AM -0400, Eli Mesika wrote: > > > >> > > > >> > > > >> ----- Original Message ----- > > > >>> From: "Yair Zaslavsky" <yzasl...@redhat.com> > > > >>> To: "Livnat Peer" <lp...@redhat.com> > > > >>> Cc: "Genadi Chereshnya" <gcher...@redhat.com>, > > > >>> engine-de...@ovirt.org, vdsm-de...@fedorahosted.org > > > >>> Sent: Sunday, October 21, 2012 5:38:54 PM > > > >>> Subject: Re: [Engine-devel] unmanaged devices thrown into > > > >>> 'custom' feature > > > >>> > > > >>> > > > >>> > > > >>> ----- Original Message ----- > > > >>>> From: "Livnat Peer" <lp...@redhat.com> > > > >>>> To: "Dan Kenigsberg" <dan...@redhat.com> > > > >>>> Cc: "Genadi Chereshnya" <gcher...@redhat.com>, > > > >>>> engine-de...@ovirt.org, vdsm-de...@fedorahosted.org > > > >>>> Sent: Sunday, October 21, 2012 5:18:31 PM > > > >>>> Subject: Re: [Engine-devel] unmanaged devices thrown into > > > >>>> 'custom' > > > >>>> feature > > > >>>> > > > >>>> On 21/10/12 16:42, Dan Kenigsberg wrote: > > > >>>>> I have just noticed that when a VM is started for the > > > >>>>> second > > > >>>>> time, > > > >>>>> Engine > > > >>>>> issues the "create" vdsm verb with some information > > > >>>>> regarding > > > >>>>> "unmanaged" devices (an example is shown below[1]) in the > > > >>>>> 'custom' > > > >>>>> propery bag. > > > >>>>> > > > >>>>> I'm surprised about this, as I was not aware of this usage > > > >>>>> of > > > >>>>> the > > > >>>>> 'custom' dictionary, and Vdsm is not doing anything with > > > >>>>> the > > > >>>>> data. > > > >>>>> > > > >>>> > > > >>>> If I recall correctly the idea of passing the unmanaged > > > >>>> devices > > > >>>> data > > > >>>> in > > > >>>> the custom property was to enable managing stable device > > > >>>> addresses > > > >>>> in > > > >>>> the hooks (to devices that were added to the VM via hooks > > > >>>> from > > > >>>> the > > > >>>> first > > > >>>> place), so this info is there not for VDSM use. > > > >>>> For example if you add a device in a hook it will be kept in > > > >>>> the > > > >>>> engine > > > >>>> as a non managed device. later when starting the VM again > > > >>>> you > > > >>>> would > > > >>>> like > > > >>>> to assign the same device address to your device, and you > > > >>>> can do > > > >>>> so > > > >>>> because you have access to the original address in the > > > >>>> custom > > > >>>> properties > > > >>>> of the VM. > > > >>> > > > >>> This is exactly what Eli has explained Gendai and Dan today. > > > > > > > > (I was asking here because I did not understand the verbal > > > > explanation.) > > > > > > > >> > > > >> This is taken from the Stable Device Address design in > > > >> http://wiki.ovirt.org/wiki/Features/Design/StableDeviceAddresses > > > >> > > > >> Unmanaged Device > > > >> ----------------- > > > >> Unmanaged Device will be supported in the new format and will > > > >> include all unhandled devices as sound/controller/etc and > > > >> future > > > >> devices. Those devices will be persistent and will have Type , > > > >> SubType (device specific) and an Address. For 3.1 an unmanaged > > > >> Device is not exposed to any GUI/REST API. Unmanaged devices > > > >> are > > > >> passed to vdsm inside a Custom property. VDSM in it turn is > > > >> passing this as is for possible hook processing. > > > > > > > > Thanks for the elaboration. Too bad that I've missed this issue > > > > before. > > > > > > > > Are you aware of any hook making use of this? I hope that hook > > > > writers > > > > are not using APIs that are not documented in vdsmd(8). > > > > > > > > It seems as a classic case where a generic bag interface is > > > > coerced > > > > into > > > > an awkward partially-documented interface. > > > > > > > > I think that a better approach would have been to pass all > > > > devices > > > > (managed and unmanaged alike) in the 'devices' property, and > > > > let > > > > vdsm > > > > expose whatever is needed to the before_vm_start hook. > > > > > > > > Maybe we can still do this. > > > > > > That was the original idea but Ayal objected and I think Igor did > > > not > > > like it as well... > > > > > > > +2. > > The original design had an 'unmanaged' (or generic) device type, > > and all > > devices should have been normalized. But as explained, this was > > strongly > > rejected in the VDSM side, causing Eli write some special handling > > for this anomaly. > > Can someone (Ayal?) explain the rejection on Vdsm side? > Hiding part of the API in the custom propery bag requires strong > reasoning indeed. >
I can't recall any rejection from my side > Dan. > > _______________________________________________ > Engine-devel mailing list > engine-de...@ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > _______________________________________________ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
