Open Stack

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>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 at 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131120/63d725f0/attachment.html>