I don't think so. Once we implement the OVSDB support, we will deprecate using the CLI commands in ovs_lib.
On Tue, Jun 17, 2014 at 12:50 PM, racha <ben...@gmail.com> wrote: > Hi, > Does it make sense also to have the choice between ovs-ofctl CLI and a > direct OF1.3 connection too in the ovs-agent? > > Best Regards, > Racha > > > > On Tue, Jun 17, 2014 at 10:25 AM, Narasimhan, Vivekanandan > <vivekanandan.narasim...@hp.com> wrote: >> >> >> >> Managing the ports and plumbing logic is today driven by L2 Agent, with >> little assistance >> >> from controller. >> >> >> >> If we plan to move that functionality to the controller, the controller >> has to be more >> >> heavy weight (both hardware and software) since it has to do the job of >> L2 Agent for all >> >> the compute servers in the cloud. , We need to re-verify all scale numbers >> for the controller >> >> on POC’ing of such a change. >> >> >> >> That said, replacing CLI with direct OVSDB calls in the L2 Agent is >> certainly a good direction. >> >> >> >> Today, OVS Agent invokes flow calls of OVS-Lib but has no idea (or >> processing) to follow up >> >> on success or failure of such invocations. Nor there is certain guarantee >> that all such >> >> flow invocations would be executed by the third-process fired by OVS-Lib >> to execute CLI. >> >> >> >> When we transition to OVSDB calls which are more programmatic in nature, >> we can >> >> enhance the Flow API (OVS-Lib) to provide more fine grained errors/return >> codes (or content) >> >> and ovs-agent (and even other components) can act on such return state >> more >> >> intelligently/appropriately. >> >> >> >> -- >> >> Thanks, >> >> >> >> Vivek >> >> >> >> >> >> From: Armando M. [mailto:arma...@gmail.com] >> Sent: Tuesday, June 17, 2014 10:26 PM >> To: OpenStack Development Mailing List (not for usage questions) >> Subject: Re: [openstack-dev] [Neutron][ML2] Modular L2 agent architecture >> >> >> >> just a provocative thought: If we used the ovsdb connection instead, do we >> really need an L2 agent :P? >> >> >> >> On 17 June 2014 18:38, Kyle Mestery <mest...@noironetworks.com> wrote: >> >> Another area of improvement for the agent would be to move away from >> executing CLIs for port commands and instead use OVSDB. Terry Wilson >> and I talked about this, and re-writing ovs_lib to use an OVSDB >> connection instead of the CLI methods would be a huge improvement >> here. I'm not sure if Terry was going to move forward with this, but >> I'd be in favor of this for Juno if he or someone else wants to move >> in this direction. >> >> Thanks, >> Kyle >> >> >> On Tue, Jun 17, 2014 at 11:24 AM, Salvatore Orlando <sorla...@nicira.com> >> wrote: >> > We've started doing this in a slightly more reasonable way for icehouse. >> > What we've done is: >> > - remove unnecessary notification from the server >> > - process all port-related events, either trigger via RPC or via monitor >> > in >> > one place >> > >> > Obviously there is always a lot of room for improvement, and I agree >> > something along the lines of what Zang suggests would be more >> > maintainable >> > and ensure faster event processing as well as making it easier to have >> > some >> > form of reliability on event processing. >> > >> > I was considering doing something for the ovs-agent again in Juno, but >> > since >> > we've moving towards a unified agent, I think any new "big" ticket >> > should >> > address this effort. >> > >> > Salvatore >> > >> > >> > On 17 June 2014 13:31, Zang MingJie <zealot0...@gmail.com> wrote: >> >> >> >> Hi: >> >> >> >> Awesome! Currently we are suffering lots of bugs in ovs-agent, also >> >> intent to rebuild a more stable flexible agent. >> >> >> >> Taking the experience of ovs-agent bugs, I think the concurrency >> >> problem is also a very important problem, the agent gets lots of event >> >> from different greenlets, the rpc, the ovs monitor or the main loop. >> >> I'd suggest to serialize all event to a queue, then process events in >> >> a dedicated thread. The thread check the events one by one ordered, >> >> and resolve what has been changed, then apply the corresponding >> >> changes. If there is any error occurred in the thread, discard the >> >> current processing event, do a fresh start event, which reset >> >> everything, then apply the correct settings. >> >> >> >> The threading model is so important and may prevent tons of bugs in >> >> the future development, we should describe it clearly in the >> >> architecture >> >> >> >> >> >> On Wed, Jun 11, 2014 at 4:19 AM, Mohammad Banikazemi <m...@us.ibm.com> >> >> wrote: >> >> > Following the discussions in the ML2 subgroup weekly meetings, I have >> >> > added >> >> > more information on the etherpad [1] describing the proposed >> >> > architecture >> >> > for modular L2 agents. I have also posted some code fragments at [2] >> >> > sketching the implementation of the proposed architecture. Please >> >> > have a >> >> > look when you get a chance and let us know if you have any comments. >> >> > >> >> > [1] https://etherpad.openstack.org/p/modular-l2-agent-outline >> >> > [2] https://review.openstack.org/#/c/99187/ >> >> > >> >> > >> >> > _______________________________________________ >> >> > OpenStack-dev mailing list >> >> > OpenStack-dev@lists.openstack.org >> >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > >> >> >> >> _______________________________________________ >> >> OpenStack-dev mailing list >> >> OpenStack-dev@lists.openstack.org >> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > >> > >> > >> > _______________________________________________ >> > OpenStack-dev mailing list >> > OpenStack-dev@lists.openstack.org >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > >> >> _______________________________________________ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> >> >> >> _______________________________________________ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev