在 2014-10-10，下午7:16，Salvatore Orlando <sorla...@nicira.com> 写道：
> Comments inline. > > Salvatore > > On 10 October 2014 11:02, Wuhongning <wuhongn...@huawei.com> wrote: > Hi, > > In the Juno cycle there is proposal of ModularL2Agent [1,2], which is very > useful to develop agent for new backend with much less redundant code. > Without that, we have to either fork a new agent by copying large amount of > existing l2agent code, or patch existing l2agent. However in the K pad [3] it > seems that this feature disappeared? > > The fact that the topic is not present in the Kilo summit discussion does not > mean that the related work item has been tabled. > It just means that it's not something we'll probably discuss at the summit, > mostly because the discussion can happen on the mailing list - as you're > doing now. > I think a summit session should be granted if the community still needs to > achieve consensus on the technical direction or if the topic is of such a > paramount importance that awareness needs to be raised. > > The blueprint and spec for this topic are available ad [1] and [2], and > afaict are still active. > > > Now there are some interest on hybrid backend (e.g. Hierachical Binding), and > some BPs are proposed to patch OVS agent. But it has two drawbacks: 1) > tightly coupled with OVS; 2) OVS agent became unnecessarily heavier. With > ML2agent we only need to add separated driver modules in the common L2agent > framework, but not to patch the monolithic ovs agent. > > The point of a modular L2 agent is to have a very efficient RPC interface > with the neutron server and a framework for detecting data plane transitions, > such as new ports, and apply the corresponding configurations. And then have > driver which will apply such configurations to different backends. > > I reckon the blueprints you are referring to are probably assuming the OVS > agent becomes modular - because otherwise it will be hardy able to target > backends which are not ovs. > > > Also if it is convenient to write only modules but not the whole agent, > backend providers may prefer to move out most of the logic from MD to agent > side driver, for better stability for Neutron controller node and easier > co-existing with other backend. Ofagent shows good compatibility of l2pop to > build vxlan/gre tunnel network between itself and other ovs/linuxbridge agent. > > Or are there any general consideration about Neutron agent side > consolidation, either L2/L3/L4-7？ > > As far as I know there is no plan for a consolidate neutron agent which does > L2/L7 operations. Frankly I do not even think there is any need for it. > No necessary consolidation of L2-7, but L2 agent consolidation, L3 agent consolidation, advanced service agent consolidation by each, but all have framework with modular drivers > > 1. https://wiki.openstack.org/wiki/Neutron/ModularL2Agent#Possible_Directions > 2. https://etherpad.openstack.org/p/juno-neutron-modular-l2-agent > 3. https://etherpad.openstack.org/p/kilo-neutron-summit-topics > > Best Regards > Wu > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > [1] https://blueprints.launchpad.net/neutron/+spec/modular-l2-agent > [2] > https://review.openstack.org/#/q/project:openstack/neutron-specs+branch:master+topic:bp/modular-L2-agent,n,z > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
