On Thu, May 22, 2014 at 01:42:55PM -0400, Federico Simoncelli wrote: > ----- Original Message ----- > > From: "Adam Litke" <[email protected]> > > To: "Dan Kenigsberg" <[email protected]> > > Cc: [email protected], "Federico Simoncelli" <[email protected]>, "Greg > > Padgett" <[email protected]> > > 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. _______________________________________________ Devel mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/devel
