Open Stack

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
deployments :)

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
offloading.


>
>> 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
>> controller.
>
> +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
>> Henry
>>
>> 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
>>> Armando
>>>
>>> _______________________________________________
>>> OpenStack-dev mailing list
>>> OpenStack-dev at lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev