On 12/19/13 5:50 PM, "Daniel P. Berrange" <[email protected]> wrote:
>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://urldefense.proofpoint.com/v1/url?u=https://wiki.openstack.org/wik >>i/Nova_VM_Diagnostics&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=eH0pxTUZo8NPZ >>yF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0A&m=vzUZT3t%2BPvKlvBTFueAjUjo8YUZvDE >>tRLmlzFb5ORuM%3D%0A&s=d13969885872ea187937a89d12aab9b36b51452ba47e35c7e41 >>692335967b9f7. 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. I am fine with this. If the data is marked optional then whoever is parsing the data should check to see if the field exists prior. > > "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 purpose of this was to be backward compatible. But I guess that if we go with the optional approach then this is redundant. > > "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. Sure, sounds reasonable. > >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" I guess that this is redundant too. > >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. Ok. I was just trying to provide an indicator for the admin to dive into the raw data. But I am fine with this. > >It would be nice to have CPU stats available too. At the moment libvirt only return the cpu0_time. Can you please let me know what other stats you would like here? > > > >> >>>https://urldefense.proofpoint.com/v1/url?u=http://berrange.com/&k=oIvRg1 >>>%2 >> >>>BdGAgOoM1BIlLLqw%3D%3D%0A&r=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq >>>8% >> >>>3D%0A&m=k92Oxw4Ev6Raba%2FayHa0ExWlFkO%2BLbCNYQYrLDivTK8%3D%0A&s=dd903dfc >>>a0 >> >b7b3ace5c560509caf1164f8f3f4dda62174e6374b07a85724183c -o- >> >>>https://urldefense.proofpoint.com/v1/url?u=http://www.flickr.com/photos/ >>>db >> >>>errange/&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=eH0pxTUZo8NPZyF6hgoMQu%2B >>>fD >> >>>tysg45MkPhCZFxPEq8%3D%0A&m=k92Oxw4Ev6Raba%2FayHa0ExWlFkO%2BLbCNYQYrLDivT >>>K8 >> >>>%3D%0A&s=3d3587124076d99d0ad02847a95a69c541cfe296f650027c99cf098aad764ab >>>9 > >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 >-- >|: >https://urldefense.proofpoint.com/v1/url?u=http://berrange.com/&k=oIvRg1%2 >BdGAgOoM1BIlLLqw%3D%3D%0A&r=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8% >3D%0A&m=vzUZT3t%2BPvKlvBTFueAjUjo8YUZvDEtRLmlzFb5ORuM%3D%0A&s=3b9f7af3a2bc >4ffaf73f6cff69fd1e88b2af95ced9b60945bc1e2f97ebaf7da4 -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=vzUZT3t%2BPvKlvBTFueAjUjo8YUZvDEtRLmlzFb5ORuM%3 >D%0A&s=3fa5cf45352c4dcbedf56f5ba059edf46fec10637a329c808cdfca2f66d3a4ce :| >|: >https://urldefense.proofpoint.com/v1/url?u=http://libvirt.org/&k=oIvRg1%2B >dGAgOoM1BIlLLqw%3D%3D%0A&r=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3 >D%0A&m=vzUZT3t%2BPvKlvBTFueAjUjo8YUZvDEtRLmlzFb5ORuM%3D%0A&s=4bf16f2a8e571 >3d2fb13f8dcb0ab13e78a5ec376b215f6c07476f4a75c1b829f -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=vzUZT3t%2BPvKlvBTFueAjUjo8YUZvDEtRLmlzFb5ORuM%3D%0A&s=1d14716b >524d2c056cb5b26f32b13df0a602ca98fb80380d7e1964491f43b44f :| >|: >https://urldefense.proofpoint.com/v1/url?u=http://autobuild.org/&k=oIvRg1% >2BdGAgOoM1BIlLLqw%3D%3D%0A&r=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8 >%3D%0A&m=vzUZT3t%2BPvKlvBTFueAjUjo8YUZvDEtRLmlzFb5ORuM%3D%0A&s=ddcbd034b66 >ac7c6ad71aa7d610c4286edd6b318b1571217479975d0f93ab2a2 -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=vzUZT3t%2BPvKlvBTFueAjUjo8YUZvDEtRLmlzFb5ORuM%3D%0A&s= >ee1de07a4232052114216c584542a5c6e1dd9bbe2998e84e170d5cdc7f7dbaf1 :| >|: >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=vzUZT3t%2BPvKlvBTFueAjUjo8YUZvDEtRLmlzFb5ORuM%3D%0A&s=f5bbef >56d9b91e55d6ad4bc09cbda2365cbc21715ba40d922f24de2960daa3a1 -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=vzUZT3t%2BPvKlvBTFueAjUjo8YUZvDEtRLmlzFb5ORuM%3D%0A&s=db9 >d0a174f481fbbb3dd4e04e9fc2666b89e1a08b0ed0ed3e2bbb2de0d4cea76 :| _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
