----- Original Message ----- > From: "Dan Kenigsberg" <[email protected]> > To: "Federico Simoncelli" <[email protected]> > Cc: [email protected], "Greg Padgett" <[email protected]>, "Adam Litke" > <[email protected]> > Sent: Tuesday, May 27, 2014 3:23:45 PM > Subject: Re: [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" <[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 > ;-)
Sorry, what I wanted to say is that I agree with Adam. The filtering should happen in getVMList with the code mentioned in the above one liner. No need for getVolumeChain. -- Federico _______________________________________________ Devel mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/devel
