[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']] -- Adam Litke
----- 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? -- Federico
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.
----- Original Message -----
From: "Dan Kenigsberg" <danken@redhat.com> To: "Federico Simoncelli" <fsimonce@redhat.com> Cc: devel@ovirt.org, "Greg Padgett" <gpadgett@redhat.com>, "Adam Litke" <alitke@redhat.com> 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" <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 ;-)
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
participants (3)
-
Adam Litke -
Dan Kenigsberg -
Federico Simoncelli