<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">2016-09-23 20:38 GMT+08:00 Daniel P. Berrange <span dir="ltr"><<a href="mailto:berrange@redhat.com" target="_blank">berrange@redhat.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="gmail-HOEnZb"><div class="gmail-h5">On Fri, Sep 23, 2016 at 07:32:36AM -0500, Matt Riedemann wrote:<br>
> On 9/23/2016 3:54 AM, Daniel P. Berrange wrote:<br>
> > On Thu, Sep 22, 2016 at 01:54:21PM -0500, Matt Riedemann wrote:<br>
> > > Sergey is working on a spec to use the standardized virt driver instance<br>
> > > diagnostics in the os-diagnostics API. A question came up during review of<br>
> > > the spec about how to define a disk 'id':<br>
> > ><br>
> > > <a href="https://review.openstack.org/#/c/357884/2/specs/ocata/approved/restore-vm-diagnostics.rst@140" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/c/357884/2/specs/ocata/<wbr>approved/restore-vm-<wbr>diagnostics.rst@140</a><br>
> > ><br>
> > > The existing diagnostics code doesn't set a disk id in the list of disk<br>
> > > dicts, but I think with at least libvirt we can set that to the target<br>
> > > device from the disk device xml.<br>
> > ><br>
> > > The xenapi code for getting this info is a bit confusing for me at least,<br>
> > > but it looks like it's possible to get the disks, but the id might need to<br>
> > > be parsed out (as a side note, it looks like the cpu/memory/disk diagnostics<br>
> > > are not even populated in the get_instance_diagnostics method for xen).<br>
> > ><br>
> > > vmware is in the same boat as xen, it's not fully implemented:<br>
> > ><br>
> > > <a href="https://github.com/openstack/nova/blob/64cbd7c51a5a82b965dab53eccfaecba45be9c27/nova/virt/vmwareapi/vmops.py#L1561" rel="noreferrer" target="_blank">https://github.com/openstack/<wbr>nova/blob/<wbr>64cbd7c51a5a82b965dab53eccfaec<wbr>ba45be9c27/nova/virt/<wbr>vmwareapi/vmops.py#L1561</a><br>
> > ><br>
> > > Hyper-v and Ironic virt drivers haven't implemented get_instance_diagnostics<br>
> > > yet.<br>
> ><br>
> > The key value of this field (which we should call "device_name", not "id"),<br>
> > is to allow the stats data to be correlated with the entries in the block<br>
> > device mapping list used to configure storage when bootin the VM. As such<br>
> > we should declare its value to match the corresponding field in BDM.<br>
> ><br>
> > Regards,<br>
> > Daniel<br>
> ><br>
><br>
> Well, except that we don't want people specifying a device name in the block<br>
> device list when creating a server, and the libvirt driver ignores that<br>
> altogether. In fact, I think Dan Smith was planning on adding a microversion<br>
> in Ocata to remove that field from the server create request since we can't<br>
> guarantee it's what you'll end up with for all virt drivers.<br>
<br>
</div></div>We don't want people specifying it, but we should report the auto-allocated<br>
names back when you query the data after instance creation, don't we ? If<br>
we don't, then there's no way for users to correlate the disks that they<br>
requested with the instance diagnostic stats, which severely limits their<br>
usefulness.<br></blockquote><div><br></div><div>So what use-case for this API? I thought it is used by admin user to diagnose the cloud. If that is the right use-case, we can expose the disk image path in the API for admin user to correlate the disks. In the libvirt, it would looks like "/opt/stack/data/nova/instances/cbc7985c-434d-4ec3-8d96-d99ad6afb618/disk". As this is admin-only API, and for diagnostics, this info is safe to expose in this API.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<span class="gmail-im gmail-HOEnZb"><br>
> I'm fine with calling the field device_name though.<br>
<br>
<br>
</span><span class="gmail-im gmail-HOEnZb">Regards,<br>
Daniel<br>
--<br>
|: <a href="http://berrange.com" rel="noreferrer" target="_blank">http://berrange.com</a> -o- <a href="http://www.flickr.com/photos/dberrange/" rel="noreferrer" target="_blank">http://www.flickr.com/photos/<wbr>dberrange/</a> :|<br>
|: <a href="http://libvirt.org" rel="noreferrer" target="_blank">http://libvirt.org</a> -o- <a href="http://virt-manager.org" rel="noreferrer" target="_blank">http://virt-manager.org</a> :|<br>
|: <a href="http://autobuild.org" rel="noreferrer" target="_blank">http://autobuild.org</a> -o- <a href="http://search.cpan.org/~danberr/" rel="noreferrer" target="_blank">http://search.cpan.org/~<wbr>danberr/</a> :|<br>
|: <a href="http://entangle-photo.org" rel="noreferrer" target="_blank">http://entangle-photo.org</a> -o- <a href="http://live.gnome.org/gtk-vnc" rel="noreferrer" target="_blank">http://live.gnome.org/gtk-vnc</a> :|<br>
<br>
</span><div class="gmail-HOEnZb"><div class="gmail-h5">______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
</div></div></blockquote></div><br></div></div>