hi Matt: noticed there is no consensus there[1], any progress outside the ML?
[1] http://lists.openstack.org/pipermail/openstack-dev/2013- October/016385.html 2013/11/21 Oleg Gelbukh <ogelb...@mirantis.com> > Matt, > > Thank you for bringing this up. I've been following this thread and the > idea is somewhat aligned with our approach, but we'd like to take one step > further. > > In this Diagnostic API, we want to collect information about system state > from sources outside to OpenStack. We'd probably should extract this call > from Nova API and use it in our implementation to get hypervisor-specific > information about virtual machines which exist on the node. But the idea is > to get vision into the system state alternative to that provided by > OpenStack APIs. > > May be we should reconsider our naming to avoid confusion and call this > Instrumentation API or something like that? > > -- > Best regards, > Oleg Gelbukh > > > On Wed, Nov 20, 2013 at 6:45 PM, Matt Riedemann < > mrie...@linux.vnet.ibm.com> wrote: > >> >> >> On Wednesday, November 20, 2013 7:52:39 AM, Oleg Gelbukh wrote: >> >>> Hi, fellow stackers, >>> >>> There was a conversation during 'Enhance debugability' session at the >>> summit about Diagnostic API which allows gate to get 'state of world' >>> of OpenStack installation. 'State of world' includes hardware- and >>> operating system-level configurations of servers in cluster. >>> >>> This info would help to compare the expected effect of tests on a >>> system with its actual state, thus providing Tempest with ability to >>> see into it (whitebox tests) as one of possible use cases. Another use >>> case is to provide input for validation of OpenStack configuration files. >>> >>> We're putting together an initial version of data model of API with >>> example values in the following etherpad: >>> https://etherpad.openstack.org/p/icehouse-diagnostic-api-spec >>> >>> This version covers most hardware and system-level configurations >>> managed by OpenStack in Linux system. What is missing from there? What >>> information you'd like to see in such an API? Please, feel free to >>> share your thoughts in ML, or in the etherpad directly. >>> >>> >>> -- >>> Best regards, >>> Oleg Gelbukh >>> Mirantis Labs >>> >>> >>> _______________________________________________ >>> OpenStack-dev mailing list >>> OpenStack-dev@lists.openstack.org >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >> >> Hi Oleg, >> >> There has been some discussion over the nova virtapi's get_diagnostics >> method. The background is in a thread from October [1]. The timing is >> pertinent since the VMware team is working on implementing that API for >> their nova virt driver [2]. The main issue is there is no consistency >> between the nova virt drivers and how they would implement the >> get_diagnostics API, they only return information that is >> hypervisor-specific. The API docs and current Tempest test covers the >> libvirt driver's implementation, but wouldn't work for say xen, vmware or >> powervm drivers. >> >> I think the solution right now is to namespace the keys in the dict that >> is returned from the API so a caller could at least check for that and know >> how to handle processing the result, but it's not ideal. >> >> Does your solution take into account the nova virtapi's get_diagnostics >> method? >> >> [1] http://lists.openstack.org/pipermail/openstack-dev/2013- >> October/016385.html >> [2] https://review.openstack.org/#/c/51404/ >> >> -- >> >> Thanks, >> >> Matt Riedemann >> >> > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- *---------------------------------------* *Lingxian Kong* Huawei Technologies Co.,LTD. IT Product Line CloudOS PDU China, Xi'an Mobile: +86-18602962792 Email: konglingx...@huawei.com; anlin.k...@gmail.com
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
