On 12/16/13 5:25 PM, "Daniel P. Berrange" <berra...@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@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 _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev