[openstack-dev] [Neutron][L2 Agent][Debt] Bootstrapping an L2 agent debt repayment task force
henry4hly at gmail.com
Wed Nov 26 01:31:57 UTC 2014
On Wed, Nov 26, 2014 at 12:14 AM, Mathieu Rohon <mathieu.rohon at gmail.com> wrote:
> On Tue, Nov 25, 2014 at 9:59 AM, henry hly <henry4hly at gmail.com> wrote:
>> Hi Armando,
>> Indeed agent-less solution like external controller is very
>> interesting, and in some certain cases it has advantage over agent
>> solution, e.g. software installation is prohibited on Compute Node.
>> However, Neutron Agent has its irreplaceable benefits: multiple
>> backends support like SRIOV, macvtap, vhost-user snabbswitch, hybrid
>> vswitch solution like NIC offloading or VDP based TOR offloading...All
>> these backend can not be easily controlled by an remote OF controller.
> Moreover, this solution is tested by the gate (at least ovs), and is
> simpler for small deployments
Not only for small deployments, but also for large scale production
We have deployed more than 500 hosts in the customer production
cluster. Now we are doing some tuning on L2pop / SG / DHCPagent, after
that 1000 nodes cluster is expected to be supported. Also for vxlan
data plane performance, we upgraded the host kernel to 3.14 (with udp
tunnel gro/gso), and it has awful satisfied performance.
The customers have very positive feedback, they have never thought
that openstack bulit-in ovs backend can work so fine, without any help
from external controller platforms, or any special hardware
>> Also considering DVR (maybe with upcoming FW for W-E), and Security
>> Group, W-E traffic control capability gap still exists between linux
>> stack and OF flowtable, whether features like advanced netfilter, or
>> performance for webserver app which incur huge concurrent sessions
>> (because of basic OF upcall model, the more complex flow rule, the
>> less megaflow aggregation might take effect)
>> Thanks to L2pop and DVR, now many customer give the feedback that
>> Neutron has made great progressing, and already meet nearly all their
>> L2/L3 connectivity W-E control directing (The next big expectation is
>> N-S traffic directing like dynamic routing agent), without forcing
>> them to learn and integrate another huge platform like external SDN
> +100. Note that Dynamic routing is in progress.
>> No attention to argue on agent vs. agentless, built-in reference vs.
>> external controller, Openstack is an open community. But, I just want
>> to say that modularized agent re-factoring does make a lot of sense,
>> while forcing customer to piggyback an extra SDN controller on their
>> Cloud solution is not the only future direction of Neutron.
>> Best Regard
>> On Wed, Nov 19, 2014 at 5:45 AM, Armando M. <armamig at gmail.com> wrote:
>>> Hi Carl,
>>> Thanks for kicking this off. I am also willing to help as a core reviewer of
>>> blueprints and code
>>> submissions only.
>>> As for the ML2 agent, we all know that for historic reasons Neutron has
>>> grown to be not only a networking orchestration project but also a reference
>>> implementation that is resembling what some might call an SDN controller.
>>> I think that most of the Neutron folks realize that we need to move away
>>> from this model and rely on a strong open source SDN alternative; for these
>>> reasons, I don't think that pursuing an ML2 agent would be a path we should
>>> go down to anymore. It's time and energy that could be more effectively
>>> spent elsewhere, especially on the refactoring. Now if the refactoring
>>> effort ends up being labelled ML2 Agent, I would be okay with it, but my gut
>>> feeling tells me that any attempt at consolidating code to embrace more than
>>> one agent logic at once is gonna derail the major goal of paying down the so
>>> called agent debt.
>>> My 2c
>>> OpenStack-dev mailing list
>>> OpenStack-dev at lists.openstack.org
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
More information about the OpenStack-dev