n't like the idea of ResourceDriver and AgentDriver.]Zang
> MingJie ---06/19/2014 06:27:31 AM---Hi: I don't like the idea of
> ResourceDriver and AgentDriver. I suggested
>
> From: Zang MingJie
> To: "OpenStack Development Mailing List (not for usage questions)&q
,
Mohammad
From: Zang MingJie
To: "OpenStack Development Mailing List (not for usage questions)"
,
Date: 06/19/2014 06:27 AM
Subject: Re: [openstack-dev] [Neutron][ML2] Modular L2 agent
architecture
Hi:
I don't like the idea of Res
On Thu, Jun 19, 2014 at 11:05:53AM -0400,
Terry Wilson wrote:
> - Original Message -
> > What's the progress by Terry Wilson?
> > If not much, I'm willing to file blueprint/spec and drive it.
> >
> > thanks,
>
> I've been working on some proof-of-concept code to help flesh out ideas for
- Original Message -
> What's the progress by Terry Wilson?
> If not much, I'm willing to file blueprint/spec and drive it.
>
> thanks,
I've been working on some proof-of-concept code to help flesh out ideas for
writing the spec. I'd talked to Maru and he mentioned that he didn't think t
Hi:
I don't like the idea of ResourceDriver and AgentDriver. I suggested
use a singleton worker thread to manager all underlying setup, so the
driver should do nothing other than fire a update event to the worker.
The worker thread may looks like this one:
# the only variable store all local sta
OVS agent manipulate not only ovs flow table, but also linux stack, which
is not so easily replaced by pure openflow controller today.
fastpath-slowpath separation sounds good, but really a nightmare for high
concurrent connection application if we set L4 flow into OVS (in our
testing, vswitchd dae
What's the progress by Terry Wilson?
If not much, I'm willing to file blueprint/spec and drive it.
thanks,
On Wed, Jun 18, 2014 at 07:00:59PM +0900,
Isaku Yamahata wrote:
> Hi. Ryu provides ovs_vsctl.py library which is python equivalent to
> ovs-vsctl command. It speaks OVSDB protocl.
> https:
Hi. Ryu provides ovs_vsctl.py library which is python equivalent to
ovs-vsctl command. It speaks OVSDB protocl.
https://github.com/osrg/ryu/blob/master/ryu/lib/ovs/vsctl.py
So with the library, it's mostly mechanical change to convert
ovs_lib.py, I think.
I'm not aware other similar library writte
,
> >> 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
> >>
> >> inte
>
>
> 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
> architectu
s-agent (and even other components) can act on such return state
>> more
>>
>> intelligently/appropriately.
>>
>>
>>
>> --
>>
>> Thanks,
>>
>>
>>
>> Vivek
>>
>>
>>
>>
>>
>> From: Armando M.
gt; 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 usag
: 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
mailto:mest
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. wrote:
> just a provocative thought: If we used the ovsdb conne
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 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
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
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
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 ov
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 w
19 matches
Mail list logo
