10:41 p.m.
----- Original Message -----
From: "Martin Perina" <mperina(a)redhat.com>
To: "Eli Mesika" <emesika(a)redhat.com>
Cc: engine-devel(a)ovirt.org
Sent: Thursday, May 9, 2013 2:17:58 PM
Subject: Re: [Engine-devel] Device custom properties
----- Original Message -----
> From: "Martin Perina" <mperina(a)redhat.com>
> To: "Eli Mesika" <emesika(a)redhat.com>
> Cc: engine-devel(a)ovirt.org
> Sent: Thursday, May 9, 2013 10:31:07 AM
> Subject: Re: [Engine-devel] Device custom properties
>
>
>
> ----- Original Message -----
> > From: "Eli Mesika" <emesika(a)redhat.com>
> > To: "Martin Perina" <mperina(a)redhat.com>
> > Cc: engine-devel(a)ovirt.org
> > Sent: Sunday, May 5, 2013 9:18:07 AM
> > Subject: Re: [Engine-devel] Device custom properties
> >
> >
> >
> > ----- Original Message -----
> > > From: "Martin Perina" <mperina(a)redhat.com>
> > > To: engine-devel(a)ovirt.org
> > > Sent: Saturday, May 4, 2013 8:13:44 AM
> > > Subject: Re: [Engine-devel] Device custom properties
> > >
> > >
> > >
> > > ----- Original Message -----
> > > > From: "Martin Perina" <mperina(a)redhat.com>
> > > > To: engine-devel(a)ovirt.org
> > > > Sent: Friday, May 3, 2013 11:06:05 AM
> > > > Subject: [Engine-devel] Device custom properties
> > > >
> > > > Hi,
> > > >
> > > > I'm currently trying to implement device custom properties
> > > > infrastructure
> > > > in
> > > > ovirt-engine.
> > > > During discussion with Yair, we found out, that it's not clear,
for
> > > > what
> > > > type
> > > > of devices
> > > > custom properties should be available? In engine we have the
> > > > VmDeviceType
> > > > enum which
> > > > contains following values:
> > > >
> > > > FLOPPY("floppy", "14"),
> > > > DISK("disk", "17"),
> > > > CDROM("cdrom", "15"),
> > > > INTERFACE("interface", "10"),
> > > > BRIDGE("bridge", "3"),
> > > > VIDEO("video", "20"),
> > > > USB("usb", "23"),
> > > > CONTROLLER("controller", "23"),
> > > > REDIR("redir", "23"),
> > > > SPICEVMC("spicevmc", "23"),
> > > > QXL("qxl"),
> > > > CIRRUS("cirrus"),
> > > > SOUND("sound"),
> > > > ICH6("ich6"),
> > > > AC97("ac97"),
> > > > MEMBALLOON("memballoon"),
> > > > SMARTCARD("smartcard"),
> > > > BALLOON("balloon"),
> > > > OTHER("other", "0"),
> > > > UNKNOWN("unknown", "-1");
> > > >
> > > > But VmDevice class has two String attributes device and type. So for
> > > > example
> > > > a disk is a device
> > > > which has device set to disk and type set to disk (according to
> > > > VmDeviceCommonUtils.isDisk method).
> > > >
> > > > So my question is, if I have a custom properties for disk, will they
> > > > be
> > > > available for all disk
> > > > devices (disk, cdrom, floppy, ...) or only for real disk? So should
> > > > we
> > > > support custom properties
> > > > for all VmDeviceType enum value separately?
> > > >
> > > > Thanks for suggestions
> > > >
> > > > Martin
> >
> > The reason for that difference is that we had types in the backend code
> > only
> > for managed devices . (i.e. devoices that are known and handled by the
> > backend)
> > Any other device as balloon etc. is considered as unmanaged device , that
> > means that VDSM tells us that it exists and therefore tell us its type as
> > well...
> >
> >
>
> Ok, I understand this.
>
> But there are also OTHER and UNKNOWN device types in backend, but these
> types
> doesn't
> corresponds to ANY type in VDSM. I don't want to refactor VmDevice device
> and
> type attributes
> too much, so is it safe to expect that device attribute of VmDevice can
> only
> contain
> one of VDSM device types ('disk', 'interface', 'video',
'sound',
> 'controller', 'balloon',
> 'channel', 'console', 'smartcard')? It's really
important question, because
> replacing
> String type with enum would save a lot of code in device custom properties
> implementation.
>
Sorry, I wrote wrong attribute. Do you think it's safe to expect that type
attribute
of VmDevice can only contain one of VDSM device types ('disk',
'interface',
'video', 'sound',
'controller', 'balloon', 'channel', 'console',
'smartcard')?
That sounds good to me.
I support this apporach.
Martin
_______________________________________________
Engine-devel mailing list
Engine-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel