Open Stack

No. ovs_lib invokes both ovs-vsctl and ovs-ofctl.
ovs-vsctl speaks OVSDB protocol, ovs-ofctl speaks OF-wire.

thanks,

On Tue, Jun 17, 2014 at 01:25:59PM -0500,
Kyle Mestery <mestery at noironetworks.com> wrote:

> 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 <benali at 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.narasimhan at 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:armamig at 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 <mestery at 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 <sorlando at 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 <zealot0630 at 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 <mb at 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 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
> >> >
> >>
> >> _______________________________________________
> >> 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
> >
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-- 
Isaku Yamahata <isaku.yamahata at gmail.com>