Hi Ajay,
What do you mean by keeping both the schemes around ? Do you mean to
have both the schemes and make it configurable to choose one of them
until a final decision is made which one to keep ?
Shall we abandon the review https://review.opencontrail.org/#/c/10123/
on api_server and work on adding this refactor code to
contrail-neutron-plugin or you want this to be merged (ofcourse after
the code reviews and CI passes :) ) first ?
Thanks
Numan
On 05/27/2015 01:12 AM, Hampapur Ajay wrote:
Hi Edouard,
Placing the adaptation from neutron to contrail representation outside
of api-server seems
logical(and beneficial since 2 cores can be used by the 2
processes) but we have to consider the fact that this layer of code is
performance sensitive (especially for list) and being restricted to
neutron-server's environment (eventlet based + changing at a pace that
we don't influence) may be limiting. We may have to keep both schemes
around (vnc_openstack with neutron_plugin_db.py running in context of
api-server and the refactor to neutron_plugin_db.py running in context
of neutron-server) till they achieve parity for testing + scale
performance.
Thanks
ajay
------------------------------------------------------------------------
*From:* Édouard Thuleau <[email protected]>
*Sent:* Sunday, May 24, 2015 2:03 AM
*To:* [email protected]
*Cc:* Nachi Ueno; Hampapur Ajay; Numan Siddique; Babu Shanmugam
*Subject:* Re: [opencontrail-dev] New Neutron OpenContrail plugin
Oops the mail was sent to quick...
I re-write it from scratch:
Hi all,
As you already know Numan and Babu refactored an re-organize the
vnc_openstack code [1]. And you also probably know, the OpenStack
Neutron project decided to move all plugins and service plugins
outside the Neutron tree [2].
Nachi already proposed a review to split the OpenContrail plugin code
in the neutron tree [3]. With that patch, Neutron tree will contain
only a plugin folder that adds python dependency to
contrail-neutron-plugin [4]. That means all the Contrail plugin code
is external to Neutron repository.
So what I propose it's to merge new vnc_openstack code to the
contrail-neutron-plugin repository and deprecated the old
vnc_openstack code into the Contrail API to remove in the future.
Any thoughts?
[1] https://www.mail-archive.com/[email protected]/msg00065.html
[2]
https://github.com/openstack/neutron-specs/blob/master/specs/kilo/core-vendor-decomposition.rst
[3] https://review.openstack.org/#/c/163218/
[4] https://github.com/Juniper/contrail-neutron-plugin
<https://github.com/Juniper/contrail-neutron-plugin>
Regards,
Édouard.
On Sun, May 24, 2015 at 1:31 AM, Édouard Thuleau
<[email protected] <mailto:[email protected]>> wrote:
Hi all,
As you already know Numan and Babu refactored an re-organize the
vnc_openstack code [1]. And you also probably know, the OpenStack
Neutron project decided to move all plugins and service plugins
outside the Neutron tree [2].
Nachi already proposed a review to split the OpenContr
It's why I propose to create a
[1]
https://www.mail-archive.com/[email protected]/msg00065.html
[2]
https://github.com/openstack/neutron-specs/blob/master/specs/kilo/core-vendor-decomposition.rst
https://review.openstack.org/#/c/163218/
_______________________________________________
Dev mailing list
[email protected]
http://lists.opencontrail.org/mailman/listinfo/dev_lists.opencontrail.org
_______________________________________________
Dev mailing list
[email protected]
http://lists.opencontrail.org/mailman/listinfo/dev_lists.opencontrail.org
