[ovirt-devel] [vdsm] VM volume chain information in getVMList API

[Dan Kenigsberg]

On Thu, May 22, 2014 at 01:42:55PM -0400, Federico Simoncelli wrote:
> ----- Original Message -----
> > From: "Adam Litke" <alitke at redhat.com>
> > To: "Dan Kenigsberg" <danken at redhat.com>
> > Cc: devel at ovirt.org, "Federico Simoncelli" <fsimonce at redhat.com>, "Greg Padgett" <gpadgett at 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.