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