Open Stack

Not if you use ODL, and we don't want to reinvent that wheel. But by
skipping CLI commands and instead using OVSDB programmatically from
agent to ovs-vswitchd, that's a decent improvement.

On Tue, Jun 17, 2014 at 11:56 AM, Armando M. <armamig at gmail.com> wrote:
> 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
>