On Wed, Nov 26, 2014 at 12:14 AM, Mathieu Rohon <[email protected]> wrote: > On Tue, Nov 25, 2014 at 9:59 AM, henry hly <[email protected]> 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. <[email protected]> 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 >>> [email protected] >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >> >> _______________________________________________ >> OpenStack-dev mailing list >> [email protected] >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
