[openstack-dev] [nova] VM diagnostics - V3 proposal

Gary Kotton gkotton at vmware.com
Mon Dec 16 15:46:35 UTC 2013



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

>On Mon, Dec 16, 2013 at 06:58:24AM -0800, Gary Kotton wrote:
>> Hi,
>> At the moment the administrator is able to retrieve diagnostics for a
>>running VM. Currently the implementation is very loosely defined, that
>>is, each driver returns whatever they have to return. This is
>>problematic in a number of respects:
>> 
>>  1.  The tempest tests were written specifically for one driver and
>>break with all other drivers (the test was removed to prevent this ­ bug
>>1240043)
>>  2.  An admin is unable to write tools that may work with a hybrid cloud
>>  3.  Adding support for get_diagnostics for drivers that do not support
>>is painful
>
>Technically 3 is currently easy, since currently you don't need to care
>about what the other drivers have done - you can return any old info
>for your new driver's get_diagnostics API impl ;-)

To be honest it was not easy at all.

>
>Seriously though, I agree the current API is a big trainwreck.
>
>> 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.

I will add this to the wiki. Not sure what this will achieve - other than
the fact that it will crystalize the fact that we need to have common data
returned.

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

This is configurable. The default is for an admin user. This is in the
policy.json file - 
https://github.com/openstack/nova/blob/master/etc/nova/policy.json#L202

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

Host diagnostics would be a nice feature to have. I do not think that it
is part of the scope of what we want to achieve here but I will certainly
be happy to work on this afterwards.

>
>
>>  2.  We enable the driver to add extra information that will assist the
>>administrators in troubleshooting problems for VM's
>> 
>> I have proposed a BP for this -
>>https://urldefense.proofpoint.com/v1/url?u=https://blueprints.launchpad.n
>>et/nova/%2Bspec/diagnostics-namespace&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A
>>&r=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0A&m=xY7Bdz7UGQQFxbe2
>>g6zVO%2FBUpkZfN%2BImM564xugLjsk%3D%0A&s=9d0ecd519b919b6c87bbdd2e1e1bf9a51
>>6f469143d15797d272cfd8c7e2d0686 (I'd like to change the name to
>>v3-api-diagnostics ­ which is more apt)
>
>The bp rename would be a good idea.
>
>> [1] 
>>https://urldefense.proofpoint.com/v1/url?u=https://etherpad.openstack.org
>>/p/vm-diagnostics&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=eH0pxTUZo8NPZyF6h
>>goMQu%2BfDtysg45MkPhCZFxPEq8%3D%0A&m=xY7Bdz7UGQQFxbe2g6zVO%2FBUpkZfN%2BIm
>>M564xugLjsk%3D%0A&s=d1386b91ca07f5504844e7f4312dc5b53b709660fe71ca96c76c3
>>8d447bec2e5
>
>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=xY7Bdz7UGQQFxbe2g6zVO%2FBUpkZfN%2BImM564xugLjsk%3D%0A&s=c421c25857
>f1ca0294b5cc318e87a758a2b49ecc35b3ca9f75b57be574ce0299      -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=xY7Bdz7UGQQFxbe2g6zVO%2FBUpkZfN%2BImM564xugLjsk
>%3D%0A&s=281520d30342d840da18dac821fdc235faf903c0bb7e8fcb51620217bf7b236a
>:|
>|: 
>https://urldefense.proofpoint.com/v1/url?u=http://libvirt.org/&k=oIvRg1%2B
>dGAgOoM1BIlLLqw%3D%3D%0A&r=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3
>D%0A&m=xY7Bdz7UGQQFxbe2g6zVO%2FBUpkZfN%2BImM564xugLjsk%3D%0A&s=9424295e978
>7fe72415305745f36556f0b8167ba0da8ac9632a4f8a183a926aa              -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=xY7Bdz7UGQQFxbe2g6zVO%2FBUpkZfN%2BImM564xugLjsk%3D%0A&s=4272f4
>851d45593104dbe068b2bd1401116bdc25852713058d1aa6797d30f36f :|
>|: 
>https://urldefense.proofpoint.com/v1/url?u=http://autobuild.org/&k=oIvRg1%
>2BdGAgOoM1BIlLLqw%3D%3D%0A&r=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8
>%3D%0A&m=xY7Bdz7UGQQFxbe2g6zVO%2FBUpkZfN%2BImM564xugLjsk%3D%0A&s=d1c7e297f
>d39ad368260bb05eb27ebf943faa781e9bd27ec99db6998a6bfbaab       -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=xY7Bdz7UGQQFxbe2g6zVO%2FBUpkZfN%2BImM564xugLjsk%3D%0A&
>s=e808b88fa336726a32fc89ff8ae5406ef91f8dfa9707ac72a8fe1a48bebc9715 :|
>|: 
>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=xY7Bdz7UGQQFxbe2g6zVO%2FBUpkZfN%2BImM564xugLjsk%3D%0A&s=d75b
>30e21a7bb90db9f674fdd50adb023765dac3fa485fbddd899027103b3312       -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=xY7Bdz7UGQQFxbe2g6zVO%2FBUpkZfN%2BImM564xugLjsk%3D%0A&s=8
>e2333f1982194bbbe7e850ff9b14dbacb1fe4c43ab23bac38ac436ac217dfae :|
>
>_______________________________________________
>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=xY7Bdz7UGQQFxbe2g6zVO
>%2FBUpkZfN%2BImM564xugLjsk%3D%0A&s=6263f7141e2006ceca49349ec950937629ae7f0
>3d2abab68612d1541cc36dcfb




More information about the OpenStack-dev mailing list