Re: [openstack-dev] [Diagnostic] Diagnostic API: summit follow-up
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 ogelb...@mirantis.com mailto: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 mailto: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 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 mailto:OpenStack-dev@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@lists.openstack.org mailto: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 mailto:konglingx...@huawei.com;
[openstack-dev] [Diagnostic] Diagnostic API: summit follow-up
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
Re: [openstack-dev] [Diagnostic] Diagnostic API: summit follow-up
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
Re: [openstack-dev] [Diagnostic] Diagnostic API: summit follow-up
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
