Open Stack

On 11/20/2013 9:35 PM, Lingxian Kong wrote:
> 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
> <http://lists.openstack.org/pipermail/openstack-dev/2013-October/016385.html>
>
>
>
> 2013/11/21 Oleg Gelbukh <ogelbukh at mirantis.com
> <mailto:ogelbukh at 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
>     <mriedem at linux.vnet.ibm.com <mailto:mriedem at 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
>             <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 at lists.openstack.__org
>             <mailto:OpenStack-dev at lists.openstack.org>
>             http://lists.openstack.org/__cgi-bin/mailman/listinfo/__openstack-dev
>             <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
>         <http://lists.openstack.org/pipermail/openstack-dev/2013-October/016385.html>
>         [2] https://review.openstack.org/#__/c/51404/
>         <https://review.openstack.org/#/c/51404/>
>
>         --
>
>         Thanks,
>
>         Matt Riedemann
>
>
>
>     _______________________________________________
>     OpenStack-dev mailing list
>     OpenStack-dev at lists.openstack.org
>     <mailto:OpenStack-dev at 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: konglingxian at huawei.com <mailto:konglingxian at huawei.com>;
> anlin.kong at gmail.com <mailto:anlin.kong at gmail.com>

Kong,

I would suggest reading through the vmware blueprint for their 
implementation of the nova virt driver diagnostics API:

https://blueprints.launchpad.net/nova/+spec/vmware-vm-diagnostics

If there are further questions, please post those to the mailing list in 
the appropriate thread (which is probably the one you referenced).

-- 

Thanks,

Matt Riedemann