[Engine-devel] [vdsm] unmanaged devices thrown into 'custom' feature

[Ayal Baron]

----- Original Message -----
> On Tue, Oct 23, 2012 at 05:53:20AM -0400, Doron Fediuck wrote:
> > 
> > 
> > ----- Original Message -----
> > > From: "Livnat Peer" <lpeer at redhat.com>
> > > To: "Dan Kenigsberg" <danken at redhat.com>
> > > Cc: engine-devel at ovirt.org, "Genadi Chereshnya"
> > > <gcheresh at redhat.com>, vdsm-devel at 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" <yzaslavs at redhat.com>
> > > >>> To: "Livnat Peer" <lpeer at redhat.com>
> > > >>> Cc: "Genadi Chereshnya" <gcheresh at redhat.com>,
> > > >>> engine-devel at ovirt.org, vdsm-devel at 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" <lpeer at redhat.com>
> > > >>>> To: "Dan Kenigsberg" <danken at redhat.com>
> > > >>>> Cc: "Genadi Chereshnya" <gcheresh at redhat.com>,
> > > >>>> engine-devel at ovirt.org, vdsm-devel at 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.

It's not hiding anything.
Today vdsm passes the libvirt xml to the hooks + the custom properties.
If you pass 'non-managed devices' through the devices API then basically you're saying to vdsm 'here is a bunch of things I want you to ignore but be a sport and pass it on to the hooks'.
Last I checked, that mechanism is custom properties.  I don't see any reason to add another one.


> 
> Dan.
> 
> _______________________________________________
> vdsm-devel mailing list
> vdsm-devel at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
>