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