Open Stack

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 <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> 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
>>
>>
>
> _______________________________________________
> OpenStack-dev mailing list
> 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; anlin.kong at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131121/8cc553d8/attachment.html>