Open Stack

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 :|