Open Stack

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.
Thanks
Gary

On 12/16/13 5:50 PM, "Daniel P. Berrange" <berrange at redhat.com> wrote:

>On Mon, Dec 16, 2013 at 03:37:39PM +0000, John Garbutt wrote:
>> On 16 December 2013 15:25, Daniel P. Berrange <berrange at redhat.com>
>>wrote:
>> > On Mon, Dec 16, 2013 at 06:58:24AM -0800, Gary Kotton wrote:
>> >> I'd like to propose the following for the V3 API (we will not touch
>>V2
>> >> in case operators have applications that are written against this ­
>>this
>> >> may be the case for libvirt or xen. The VMware API support was added
>> >> in I1):
>> >>
>> >>  1.  We formalize the data that is returned by the API [1]
>> >
>> > Before we debate what standard data should be returned we need
>> > detail of exactly what info the current 3 virt drivers return.
>> > IMHO it would be better if we did this all in the existing wiki
>> > page associated with the blueprint, rather than etherpad, so it
>> > serves as a permanent historical record for the blueprint design.
>> 
>> +1
>> 
>> > While we're doing this I think we should also consider whether
>> > the 'get_diagnostics' API is fit for purpose more generally.
>> > eg currently it is restricted to administrators. Some, if
>> > not all, of the data libvirt returns is relevant to the owner
>> > of the VM but they can not get at it.
>> 
>> Ceilometer covers that ground, we should ask them about this API.
>
>If we consider what is potentially in scope for ceilometer and
>subtract that from what the libvirt get_diagnostics impl currently
>returns, you pretty much end up with the empty set. This might cause
>us to question if 'get_diagnostics' should exist at all from the
>POV of the libvirt driver's impl. Perhaps vmware/xen return data
>that is out of scope for ceilometer ?
>
>> > For a cloud administrator it might be argued that the current
>> > API is too inefficient to be useful in many troubleshooting
>> > scenarios since it requires you to invoke it once per instance
>> > if you're collecting info on a set of guests, eg all VMs on
>> > one host. It could be that cloud admins would be better
>> > served by an API which returned info for all VMs ona host
>> > at once, if they're monitoring say, I/O stats across VM
>> > disks to identify one that is causing I/O trouble ? IOW, I
>> > think we could do with better identifying the usage scenarios
>> > for this API if we're to improve its design / impl.
>> 
>> I like the API that helps you dig into info for a specific host that
>> other system highlight as problematic.
>> You can do things that could be expensive to compute, but useful for
>> troubleshooting.
>
>If things get expensive to compute, then it may well be preferrable to
>have separate APIs for distinct pieces of "interesting" diagnostic
>data. eg If they only care about one particular thing, they don't want
>to trigger expensive computations of things they don't care about seeing.
>
>Regards,
>Daniel
>-- 
>|: 
>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
>:|
>|: 
>https://urldefense.proofpoint.com/v1/url?u=http://libvirt.org/&k=oIvRg1%2B
>dGAgOoM1BIlLLqw%3D%3D%0A&r=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3
>D%0A&m=k92Oxw4Ev6Raba%2FayHa0ExWlFkO%2BLbCNYQYrLDivTK8%3D%0A&s=60b14571198
>7777ff9afdeb5949597de9596b75ab79abca0496a96703e15aa10              -o-
>         
>https://urldefense.proofpoint.com/v1/url?u=http://virt-manager.org/&k=oIvR
>g1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxP
>Eq8%3D%0A&m=k92Oxw4Ev6Raba%2FayHa0ExWlFkO%2BLbCNYQYrLDivTK8%3D%0A&s=a6f1f8
>5bb37036e37ed7e7dba4d88c00a289cfb0e42740528d5c7ca1bd690620 :|
>|: 
>https://urldefense.proofpoint.com/v1/url?u=http://autobuild.org/&k=oIvRg1%
>2BdGAgOoM1BIlLLqw%3D%3D%0A&r=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8
>%3D%0A&m=k92Oxw4Ev6Raba%2FayHa0ExWlFkO%2BLbCNYQYrLDivTK8%3D%0A&s=ee08dd8de
>4174a142a6d8c5aa18ede84b47ec0db358b96c3b729232e004641e1       -o-
>https://urldefense.proofpoint.com/v1/url?u=http://search.cpan.org/~danberr
>/&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45M
>kPhCZFxPEq8%3D%0A&m=k92Oxw4Ev6Raba%2FayHa0ExWlFkO%2BLbCNYQYrLDivTK8%3D%0A&
>s=313fd521d220dc3b7cbba305533de490bf614449d0489e705e15f2536657c222 :|
>|: 
>https://urldefense.proofpoint.com/v1/url?u=http://entangle-photo.org/&k=oI
>vRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZF
>xPEq8%3D%0A&m=k92Oxw4Ev6Raba%2FayHa0ExWlFkO%2BLbCNYQYrLDivTK8%3D%0A&s=da78
>6c64edaa5251e52b5fefc809d10b04a8482930f9ceccf981becc5e36ca8a       -o-
>   
>https://urldefense.proofpoint.com/v1/url?u=http://live.gnome.org/gtk-vnc&k
>=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPh
>CZFxPEq8%3D%0A&m=k92Oxw4Ev6Raba%2FayHa0ExWlFkO%2BLbCNYQYrLDivTK8%3D%0A&s=1
>f68b12b31379ea5d4e5e225a5a22195c335f3f1e09c68914e93d7db5ce3d66b :|
>
>_______________________________________________
>OpenStack-dev mailing list
>OpenStack-dev at lists.openstack.org
>https://urldefense.proofpoint.com/v1/url?u=http://lists.openstack.org/cgi-
>bin/mailman/listinfo/openstack-dev&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=e
>H0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0A&m=k92Oxw4Ev6Raba%2FayHa
>0ExWlFkO%2BLbCNYQYrLDivTK8%3D%0A&s=0330b3275aced3c5c45a644976fae364d019680
>bd257d2ea6d83b8277d3b9476