I agree, the thing to solve here is for the purely openstack activities we want to perform on the VIM.
Looking at areas like access connectivity and distributed cloud technologies these are capabilities that will most likely require more than an OpenStack northbound interface from the VIM. There is no point trying to solve non-openstack issues in openstack. They don’t need or want the complication of, for instance, trying to integrate the provisioning of a vOLT function into a VIM operation. I do agree on trying to work with openstack to keep their interface (especially those we care about) backwards compliant, for that we must be fully engaged with the community related to our needed use cases. We have the power to affect openstack and any other community when we are part of those communities. But if we don’t show up the reverse is true. Let’s make sure we know what we care about and demonstrate our care in those projects. J / Chris From: <[email protected]> on behalf of "SULLIVAN, BRYAN L" <[email protected]> Date: Thursday, 17 November 2016 at 02:32 To: yaohelan <[email protected]>, Jose Angel Lausuch Sales <[email protected]>, "Beierl, Mark" <[email protected]> Cc: TECH-DISCUSS OPNFV <[email protected]> Subject: Re: [opnfv-tech-discuss] 答复: [functest] [yardstick] Client version can't support Newton - solution proposal I would say that: 1) We should strive to directly leverage upstream clients directly, and specifically the python-openstackclient in all cases where it serves our need for the specific OPNFV system version. a. Exceptions do exist, but we will not help promote removal of those exceptions by creating a shim client that shields us from the pain of the gaps, and the OpenStack python-openstackclient project from the need to address those gaps. b. After all, we are here to identity and address-upstream issues with the upstream projects. 2) We should not own code intended as a long-term shim of an upstream project, even one that ostensibly simplifies how test code interacts with the openstack clients (the python-openstackclient or any of the others). a. An experimental shim might help the upstream teams to understand and address gaps/issues we have, but would have little real, long-term value to OPNFV beyond that. b. One key reason is any simplification/abstraction is likely to mask things that some project needs, and then we are right back to an exception/kludge situation, with the exception that to address the issue we now have to issue patches against another (and not even upstream) project. 3) We should document all issues with the plan-of-record of the OpenStack community to converge on the python-openstackclient, and put any efforts to address them directly upstream, not in OPNFV. a. For now we have plenty of workaround approaches to those issues, e.g. use a different client/version. b. The implications/limitations of those workarounds should also be documented so we can decide which really are sufferable until the upstream client issues are addressed. Thanks, Bryan Sullivan | AT&T From: [email protected] [mailto:[email protected]] On Behalf Of yaohelan Sent: Monday, November 14, 2016 7:32 PM To: Jose Lausuch <[email protected]>; Beierl, Mark <[email protected]> Cc: [email protected] Subject: [opnfv-tech-discuss] 答复: [functest] [yardstick] Client version can't support Newton - solution proposal Hi all, Here is the drafted proposal for the Newton support. Your feedback is appreciated. If you have other solution, feel free to come up with. Once we know every detail of each solution, we may vote for which one to use. A common OpenStack utility library/module is needed to handle all operations against OpenStack, and it will be used by projects including Yardstick, Functest, Storperf, Bottleneck and other projects that have the requirements to interact with OpenStack. Benefit: Only OpenStack utility library/module is required to be updated when there is any request for upgrading/change. Effort will be saved for projects and they can focus on the main business. In real world, all projects are maintaining their own repository for OpenStack operation. The effort to upgrade the process will not be shared among projects. Area to Investigate Look at the existing codes and come up with a solution to put them together. Two possible solutions to deal with client version change for different OpenStack Idea 1: Leverage OpenStackClient[1] to take care of different OpenStack version Reason: OpenStack should be able to handle the version switching and support the backward compatibility. It is quite challengeable for downstream projects to take care of the version with limited knowledge. Areas to investigate 1. Identify the all scenarios that we are leveraging clients 2. Test with OpenStackClient to make sure all scenarios can be fulfilled Risks/Challenges 1. Functest and Yardstick are mainly using components including Nova, Keystone, Neutron, Heat, etc. OpenStackClient provides a shell.py to wrapping the call into CLI and it seems that this way provides almost every possible alternatives to our currently implementation. However, if we wants to import openstackclient as module in the code, heat might be lost and we have to implement the logic to support calling different version of heatclient. 2. The learning curve might be long as it requires developers to map all of current implementation to openstackclient. Idea 2: Design the logic to handle different clients Areas to investigate 1. Come up with the client list for different OpenStack version 2. Put the client requirements into separate configuration per OpenStack version 3. Dynamically decide which configuration to use Risks/Challenges 1. A wise and general architecture is required as more OpenStack upgrades are expected [1] https://github.com/openstack/python-openstackclient 发件人: Jose Lausuch [mailto:[email protected]] 发送时间: 2016年11月11日 23:43 收件人: Beierl, Mark <[email protected]>; yaohelan <[email protected]> 抄送: liyuenan <[email protected]>; [email protected] 主题: RE: [opnfv-tech-discuss] [functest] [yardstick] Client version can't support Newton Hi, That is something to be tested. I don’t know yet. We had some problems with version in the past, that’s why we hard-code some client versions in the import commands. We created this task https://jira.opnfv.org/browse/FUNCTEST-529 to keep track of that upgrade. Helen Yao will be our hero for that activity. JOSE LAUSUCH Senior Systems Designer Ericsson From: Beierl, Mark [mailto:[email protected]] Sent: Friday, November 11, 2016 16:32 PM To: Jose Lausuch Cc: liyuenan; [email protected] Subject: Re: [opnfv-tech-discuss] [functest] [yardstick] Client version can't support Newton Hello, Jose. Question - what about the transitional state where some installers are still on v2? Will the v3 client still work? Regards, Mark Mark Beierl Advisory Solutions Architect Dell EMC | Office of the CTO mobile +1 613 314 8106 [email protected] On Nov 11, 2016, at 10:26, Jose Lausuch <[email protected]> wrote: Hi, We are aware of that and are in the process of supporting Newton in Functest. Related JIRA Epic: https://jira.opnfv.org/browse/FUNCTEST-528 Basically, there are 2 actions the test projects need to do: 1) Upgrade the OpenStack python clients (pip install --upgrade …) 2) Update the module version that is imported in the code (from neutronclient.v3_0 import client) I have created a wiki collecting this information to align in what we are installing in our Docker image https://wiki.opnfv.org/display/functest/OpenStack+python+clients Feel free to provide feedback. JOSE LAUSUCH Senior Systems Designer Ericsson From: [email protected] [mailto:[email protected]] On Behalf Of Beierl, Mark Sent: Friday, November 11, 2016 16:16 PM To: liyuenan Cc: [email protected] Subject: Re: [opnfv-tech-discuss] [functest] [yardstick] Client version can't support Newton Hello, This does raise an interesting dilemma: a project often will use the Python API directly, which means a change from v2 to v3 is a code change, not a runtime configuration change. Therefore at the moment, this is not something that is selectable per installer. I know for StorPerf, this is definitely the case, and I think I will need to propose a change where the client and API to use is dynamically selectable based on a configuration file. Does any project have such code already? Regards, Mark Mark Beierl Advisory Solutions Architect Dell EMC | Office of the CTO mobile +1 613 314 8106 [email protected] On Nov 11, 2016, at 02:58, liyuenan <[email protected]> wrote: Hi everyone! Compass4nfv can deploy Newton now, but could not test it by yardstick or functest because of API version. Newton deployed by compass4nfv use the API v3 to instead of API v2.0. So I think yardstick and functest should update client version to support Newton. Error log is in attachment. And you can deploy Newton by compass4nfv. Best Regards! Yuenan Li <functest_healthcheck_error.log><functest_prepare_error.log><yardstick_ping_error.log>_______________________________________________ opnfv-tech-discuss mailing list [email protected] https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss _______________________________________________ opnfv-tech-discuss mailing list [email protected] https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss
_______________________________________________ opnfv-tech-discuss mailing list [email protected] https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss
