Thanks, Bryan. Part of me was afraid someone was going to point out this (rather obvious) position. The "afraid" comes only from my perspective of not knowing how to go about doing this correctly (i.e. upstream) and lack of overall knowledge of the OpenStack client itself that makes me feel like I would not know where to start.
Having said that, I think I can take your point of vetting any shortcomings in an OPNFV repo and then proposing them upstream. I am just not sure if I have the time or resources to get involved in the overall "is Heat part of the OpenStack client" discussion :( What would be the next steps in moving towards this goal? Continue with the common OpenStack (and extras like Heat) library in OPNFV and then engage upstream? Regards, Mark Mark Beierl Advisory Solutions Architect Dell EMC | Office of the CTO mobile +1 613 314 8106<tel:1-613-314-8106> mark.bei...@dell.com<mailto:mark.bei...@dell.com> On Nov 16, 2016, at 20:32, SULLIVAN, BRYAN L <bs3...@att.com<mailto:bs3...@att.com>> wrote: 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: opnfv-tech-discuss-boun...@lists.opnfv.org<mailto:opnfv-tech-discuss-boun...@lists.opnfv.org> [mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] On Behalf Of yaohelan Sent: Monday, November 14, 2016 7:32 PM To: Jose Lausuch <jose.laus...@ericsson.com<mailto:jose.laus...@ericsson.com>>; Beierl, Mark <mark.bei...@dell.com<mailto:mark.bei...@dell.com>> Cc: opnfv-tech-discuss@lists.opnfv.org<mailto:opnfv-tech-discuss@lists.opnfv.org> 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:jose.laus...@ericsson.com] 发送时间: 2016年11月11日 23:43 收件人: Beierl, Mark <mark.bei...@dell.com<mailto:mark.bei...@dell.com>>; yaohelan <yaohe...@huawei.com<mailto:yaohe...@huawei.com>> 抄送: liyuenan <liyue...@huawei.com<mailto:liyue...@huawei.com>>; opnfv-tech-discuss@lists.opnfv.org<mailto:opnfv-tech-discuss@lists.opnfv.org> 主题: 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:mark.bei...@dell.com] Sent: Friday, November 11, 2016 16:32 PM To: Jose Lausuch Cc: liyuenan; opnfv-tech-discuss@lists.opnfv.org<mailto:opnfv-tech-discuss@lists.opnfv.org> 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<tel:1-613-314-8106> mark.bei...@dell.com<mailto:mark.bei...@dell.com> On Nov 11, 2016, at 10:26, Jose Lausuch <jose.laus...@ericsson.com<mailto:jose.laus...@ericsson.com>> 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: opnfv-tech-discuss-boun...@lists.opnfv.org<mailto:opnfv-tech-discuss-boun...@lists.opnfv.org> [mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] On Behalf Of Beierl, Mark Sent: Friday, November 11, 2016 16:16 PM To: liyuenan Cc: opnfv-tech-discuss@lists.opnfv.org<mailto:opnfv-tech-discuss@lists.opnfv.org> 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<tel:1-613-314-8106> mark.bei...@dell.com<mailto:mark.bei...@dell.com> On Nov 11, 2016, at 02:58, liyuenan <liyue...@huawei.com<mailto:liyue...@huawei.com>> 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 opnfv-tech-discuss@lists.opnfv.org<mailto:opnfv-tech-discuss@lists.opnfv.org> https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss
_______________________________________________ opnfv-tech-discuss mailing list opnfv-tech-discuss@lists.opnfv.org https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss
