[openstack-dev] [neutron] what happened to ModularL2Agent?
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? 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. 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？ 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
Re: [openstack-dev] [neutron] what happened to ModularL2Agent?
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. 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
Re: [openstack-dev] [neutron] what happened to ModularL2Agent?
在 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
