On Tue, Dec 17, 2013 at 04:28:30AM -0800, Gary Kotton wrote: > Hi, > Following the discussion yesterday I have updated the wiki - please see > https://wiki.openstack.org/wiki/Nova_VM_Diagnostics. The proposal is > backwards compatible and will hopefully provide us with the tools to be > able to troubleshoot VM issues.
Some comments "If the driver is unable to return the value or does not have access to it at the moment then it should return 'n/a'." I think it is better if the driver just omitted any key that it doesn't support altogether. That avoids clients / users having to do magic string comparisons to identify omitted data. "An ID for the diagnostics version. The structure defined below is version 1 (Integer)" What are the proposed semantics for version numbers. Do they incremented on any change, or only on backwards incompatible changes ? "The amount of time in seconds that the VM has been running (Integer)" I'd suggest nano-seconds here. I've been burnt too many times in the past providing APIs where we rounded data to a coarse unit like seconds. Let client programs convert from nanoseconds to seconds if they wish to display it in that way, but keep the API with the full precision. "The version of the raw data" Same question as previously. The allowed keys in network/disk/memory details seem to be unduly limited. Just having a boolean "activity" for disk or NICs seems almost entirely useless. eg the VM might have sent 1 byte when it first booted and nothing more for the next 10 days, and an admin can't see this. I'd suggest we should follow the much expanded set of possible stats shown by the libvirt driver. These are pretty common things to show for disk/nic activity and a driver wouldn't have to support all of them if it doesn't have that info. It would be nice to have CPU stats available too. > >https://urldefense.proofpoint.com/v1/url?u=http://berrange.com/&k=oIvRg1%2 > >BdGAgOoM1BIlLLqw%3D%3D%0A&r=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8% > >3D%0A&m=k92Oxw4Ev6Raba%2FayHa0ExWlFkO%2BLbCNYQYrLDivTK8%3D%0A&s=dd903dfca0 > >b7b3ace5c560509caf1164f8f3f4dda62174e6374b07a85724183c -o- > >https://urldefense.proofpoint.com/v1/url?u=http://www.flickr.com/photos/db > >errange/&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=eH0pxTUZo8NPZyF6hgoMQu%2BfD > >tysg45MkPhCZFxPEq8%3D%0A&m=k92Oxw4Ev6Raba%2FayHa0ExWlFkO%2BLbCNYQYrLDivTK8 > >%3D%0A&s=3d3587124076d99d0ad02847a95a69c541cfe296f650027c99cf098aad764ab9 BTW if you would be nice if you can get your email program not to mangle URLs in mails you're replying to. In this case it was just links in a signature so didn't matter, but in other messages it is mangled stuff in the body of the message :-( It makes it painful to read the context. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
