Closed pgoyal01 closed 4 years ago
The default should be ML2 and all Service Plugins. However, RA1 should support monolithic plugins as well - there are many deployments that use monolithic plugins (such as Contrail/Tungsten Fabric). Additionally, ONAP and OPNFV both have hooks to support it. We should discuss as to which other monolithic plugins should be included. Please include me in the discussion - as the meeting times are very odd for me (I am on Pacific time zone). Thanks -Sukhdev
At least, we should write the default set of API (here Neutron): versions, service plugins, networking features, etc. We could also consider the type drivers supported (e.g. overlays) indirectly exposed (see tempest, patrole, etc.).
From my understanding, the API is agnostic about the Neutron design (ML2 or monolithic plugin). It's true they are a few Tempest tests about agent (ref impl).
It's worth mentioning that we hadn't verified neither Open Contrail nor Tungsten Fabric via Functest in OPNFV as no installer has been able to install it successfully.
@collivier @sukhdevkapur Can we have an asynchronous discussion here in Github -- if we need a meeting for closure, will arrange one.
W.r.t. "write the default set of API", a decision was made not to duplicate OpenStack documentation but provide a reference to the specific version (in case of Neutron Version 2). If the ask is instead to list APIs, I think that is a discussion for the Technical Steering Committee.
Discussion Topic: What are the criteria for including/excluding monolithic plugins?
@pgoyal01 - I think it is reasonable not to replicate the API - instead a reference is sufficient.
Agree on Discussion topic. We should have discussion on this. Should a new issue be opened for this?
My point is not to duplicate the official documentation at all. Regarding our target, we do go one step further than listing the versions. Then I think we should select the subset of Neutron API (see Neutron extensions / services) which has to implemented and then verified.
https://github.com/cntt-n/CNTT/blob/master/doc/ref_arch/openstack/chapters/chapter05.md#5.2
We could also leverage on IRC for any asynchronous discussion(#opnfv-functest on freenode)
@collivier - I get it. I think you make a good point. The question is how do we list what is included and what is not. One suggestion will be to use Neutron tempest tests for this purpose. They allow an exclusion list. This list specifies which tests to run and which to skip. We can build an exclusion list. This is short and is not version dependent. Once we have this list, then we make it mandatory that all neutron API tests must pass. This will be a rock solid and version proof solution - I would love to hear other experts opinion on this.
@sukhdevkapur Yes that's exactly my point quickly explained in the parent topic. https://github.com/cntt-n/CNTT/issues/371#issuecomment-544117919
Thanks to that section, we should be able to build a specific functest-cntt-smoke including all tempest-based testcases (tempest_full, tempest_slow, tempest_scenario, neutron-tempest-plugin-api, patrole, etc...) and possibly all rally-based testcases. As opposed to the classic functest-smoke which is generic and then which tests as much as possible, no test will be skipped because the reference is well known.
We could also simply set here the tempest regex if we prefer a testing approach.
@rabi-abdel about gap analysis, all API are already well covered (positive and negative testing), our work is mostly to identify all subtests in Functest which can be skipped or not (see decorators in tempest). I will continuously update the testcase descriptions according to that chapter. https://github.com/cntt-n/CNTT/blob/master/doc/ref_cert/lfn/chapters/chapter11.md
@collivier @sukhdevkapur Can we have an asynchronous discussion here in Github -- if we need a meeting for closure, will arrange one.
W.r.t. "write the default set of API", a decision was made not to duplicate OpenStack documentation but provide a reference to the specific version (in case of Neutron Version 2). If the ask is instead to list APIs, I think that is a discussion for the Technical Steering Committee.
Discussion Topic: What are the criteria for including/excluding monolithic plugins?
@pgoyal01 , Can you open PR for this "What are the criteria for including/excluding monolithic plugins?" or to more Generic "Neuton API vs other plugins" i believe this one is important to be discussed as sperate topic as we need to agree if SDN should be part of our RA ( which i believe it should be "" after that we can figure on the GAP that SDN will solve and which approach"
The default should be ML2 and all Service Plugins. However, RA1 should support monolithic plugins as well - there are many deployments that use monolithic plugins (such as Contrail/Tungsten Fabric). Additionally, ONAP and OPNFV both have hooks to support it. We should discuss as to which other monolithic plugins should be included. Please include me in the discussion - as the meeting times are very odd for me (I am on Pacific time zone). Thanks -Sukhdev
@sukhdevkapur valid point, but as far as I know contrail only supporting Monoltic plugin, so we need to be careful when we covered this part in RA
@pgoyal01 seems OK to me.
Currently, Ch04 incorporates the ML-2 plugin. Per @collivier, OPNFV functest supports a few other plugins.
Source: http://artifacts.opnfv.org/functest/functest-opnfv-functest-smoke-latest-neutron-tempest-plugin-api-run-497/results/neutron-tempest-plugin-api/tempest-report.html
Need guidance on which plugins should be utilised in the RA. Depending upon decisions the RA-1 Chapter 4and Chapter 5 would be updated; an issue for RA-1 Chapter05 will be raised, if needed.