Re: [ovirt-devel] [vdsm] VM volume chain information in getVMList API
On Thu, May 22, 2014 at 01:42:55PM -0400, Federico Simoncelli wrote:
----- Original Message -----
> From: "Adam Litke" <alitke(a)redhat.com>
> To: "Dan Kenigsberg" <danken(a)redhat.com>
> Cc: devel(a)ovirt.org, "Federico Simoncelli" <fsimonce(a)redhat.com>,
"Greg Padgett" <gpadgett(a)redhat.com>
> Sent: Thursday, May 22, 2014 6:37:31 PM
> Subject: [vdsm] VM volume chain information in getVMList API
>
> For Live Merge, engine needs a way to get a list of volume UUIDs that
> comprise the volume chain for a given VM disk. Initially, we created
> a new verb getVolumeChain(vm, driveSpec) that would return a list of
> VM uuids. In the interest of preventing API bloat I would prefer to
> use the 'volumeChain' list in VmDiskDevice which is retrieved from the
> getVMList public API.
>
> Federico mentioned that this info may have been exposed by accident at
> one point and I agree that things like volume paths should not be
> used and should possibly be removed from this structure. That being
> said, we have a real use case for using the volume UUIDs and that
> should be quite safe.
>
> Do you agree with my assessment or should I continue with the
> getVolumeChain verb which does nothing more than:
>
> return [x['volumeID'] for x in vmDrive['volumeChain']]
It makes sense for me. +1, Dan?
Francesco, you cannot answer with +1 to an question with an exclusive or
;-)
I prefer to add an API call. getVMList should have returned only the
data required to recreate the VM.
I do not know whether Engine already uses volumeChain; browsing through
the vdsm side of git log, may suggest that exposing it was indeed
unintentional. Having a well-defined verb is better than our current
tendency of peppering possibly-stale data in vm.conf.
Dan.