Hi, I am in favor of creating common tools. Actually we do have common libraries that can be used by any project in the community, for example I started writing (and need to finish it soon) a installer adapter python module to access the OpenStack nodes of any OPNFV deployment. It works only for Fuel but I am planning to write it the Apex, JOID and Compass adapters too. There are other things like the Rest API, test results dashboard that is used by more than 1 project in OPNFV. So, it is not the first time we share common code :)
That said, I think if we write a common OpenStack api wrapper using whatever python client, we should place it in the same location, and that is releng. We even created a directory in the repository for that purpose: https://git.opnfv.org/cgit/releng/tree/modules We will actually start moving common code to this directory soon. Another thing to consider is the SNAPS library that is currently being integrated in Functest by Steven Pisarski and it includes exactly what Helen explained, a common OpenStack utility library/module. Maybe if the community agrees, we could consider placing it in a central place instead of Functest, but only if other projects intend to use it, otherwise it does not make sense to me. Answering to the ideas that Helen proposes, Idea-1 is good, but it does not satisfy all the needs. There are some cases that the OpenStack client can not achieve by itself. I prefer the option 2 since we don’t need to modify the code much and we can just swap a config/requirements file to use one version or the other. Regards, Jose On 15 Nov 2016, at 18:32, Christopher Price <chrispric...@gmail.com<mailto:chrispric...@gmail.com>> wrote: Hi Guys, I may be throwing our friend Bryan to the wolves here… but… Could we build this in the “models” project & repo? It would seem to fit. Keep the scope to as simple as possible, focused on needed operations with accepted info models. Provide a method of controlled deprecation (or maintenance) of i/f implementations. It could also extend to other VIM components if it works (but not immediately in deference to scope control). Just throwing it out there. / Chris From: <opnfv-tech-discuss-boun...@lists.opnfv.org<mailto:opnfv-tech-discuss-boun...@lists.opnfv.org>> on behalf of "Beierl, Mark" <mark.bei...@dell.com<mailto:mark.bei...@dell.com>> Date: Tuesday, 15 November 2016 at 18:19 To: yaohelan <yaohe...@huawei.com<mailto:yaohe...@huawei.com>> Cc: TECH-DISCUSS OPNFV <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 - solution proposal Hello, I like the idea of a common OpenStack utility library with idea #1 - the OpenStack client. This seems to me to be the cleaner and more dynamic approach, and probably has the best support path going forward. If I understand correctly, the other libraries (or at least clients) are being deprecated in favour of OpenStack client. With that being said, I am not sure the OpenStack client has Heat (as an example) in its scope, which may force us into idea #2 either way. This will be the first time (I think) that there is a proposal for OPNFV projects to share common code. Some issues for discussion: * What git repo holds the code? * What project owns the git repo? (This addresses who the committers will be) * What JIRA project tracks issues and work items? 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 14, 2016, at 22:31, yaohelan <yaohe...@huawei.com<mailto:yaohe...@huawei.com>> wrote: 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<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<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
