On 12/19/13 6:07 PM, "Daniel P. Berrange" <berra...@redhat.com> wrote:
>On Thu, Dec 19, 2013 at 08:02:16AM -0800, Gary Kotton wrote: >> >> >> On 12/19/13 5:50 PM, "Daniel P. Berrange" <berra...@redhat.com> 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/w >>>>ik >> >>>>i/Nova_VM_Diagnostics&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=eH0pxTUZo8N >>>>PZ >> >>>>yF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0A&m=vzUZT3t%2BPvKlvBTFueAjUjo8YUZv >>>>DE >> >>>>tRLmlzFb5ORuM%3D%0A&s=d13969885872ea187937a89d12aab9b36b51452ba47e35c7e >>>>41 >> >>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. > >Oh hang on, when you say 'amount of time in seconds the VM has been >running' >you're meaning wall-clock time since boot. Seconds is fine for wall clock >time actually. > > >I was getting mixed up with CPU utilization time, since libvirt doesn't >actually provide any way to get "uptime". > > >> >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? > >Since we have numCpus, I'd suggest we allow for a list of cpus in the >same way we do for disk/nics and returning the execution time split >out for each vCPU. We could still have a merged execution time too >since I can imagine some hypervisors won't be able to provide the >split out per-vcpu time. Good call. I'll add this! > >Daniel >-- >|: >https://urldefense.proofpoint.com/v1/url?u=http://berrange.com/&k=oIvRg1%2 >BdGAgOoM1BIlLLqw%3D%3D%0A&r=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8% >3D%0A&m=np3rsZrtAfOFOfhCRXiCtSXdJPm3QIwaKWcO75QdIvo%3D%0A&s=43e28d32e5a671 >8ba104d118a69e659866e10cb5981b43bd8c89ac09d96bc6de -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=np3rsZrtAfOFOfhCRXiCtSXdJPm3QIwaKWcO75QdIvo%3D% >0A&s=69b56c12bb439e62c6aa90ec908016b701d268210a464d9d1f43f8c070e6e1db :| >|: >https://urldefense.proofpoint.com/v1/url?u=http://libvirt.org/&k=oIvRg1%2B >dGAgOoM1BIlLLqw%3D%3D%0A&r=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3 >D%0A&m=np3rsZrtAfOFOfhCRXiCtSXdJPm3QIwaKWcO75QdIvo%3D%0A&s=d4d36b4c778f308 >9290ed06239bad90dbe8b52370f9c6c24b60a935510fb74d7 -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=np3rsZrtAfOFOfhCRXiCtSXdJPm3QIwaKWcO75QdIvo%3D%0A&s=edb1182136 >b3c880b14557de1856e0fbb4a950fceb89b39bb0cef7df081fa10c :| >|: >https://urldefense.proofpoint.com/v1/url?u=http://autobuild.org/&k=oIvRg1% >2BdGAgOoM1BIlLLqw%3D%3D%0A&r=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8 >%3D%0A&m=np3rsZrtAfOFOfhCRXiCtSXdJPm3QIwaKWcO75QdIvo%3D%0A&s=42e39e02e8829 >734ca2e30d74e1eeee0da2b0b3467c1cf019dc51c2edf1886f1 -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=np3rsZrtAfOFOfhCRXiCtSXdJPm3QIwaKWcO75QdIvo%3D%0A&s=ef >96fb0514240a8fb1a14e4a75889bfc885abd1c4513c2a247cc3ea9d8c6a5d8 :| >|: >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=np3rsZrtAfOFOfhCRXiCtSXdJPm3QIwaKWcO75QdIvo%3D%0A&s=e3b5989e >44bc56357ec2ad6d0e5362628f44091fd2f7db207e6328512bd92b9a -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=np3rsZrtAfOFOfhCRXiCtSXdJPm3QIwaKWcO75QdIvo%3D%0A&s=d33ad >8192121a93a6f313b74f77c8b7add4967d4430f88a0fd11cbe80ee1e5f3 :| _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
