Open Stack

Comments inline.

Salvatore

On 10 October 2014 11:02, Wuhongning <wuhongning at 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 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141010/f033975e/attachment.html>