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. 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. 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. <arma...@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 > OpenStackemail@example.com > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > _______________________________________________ OpenStack-dev mailing list OpenStackfirstname.lastname@example.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev