Talked off-line but also post my thought.

In short, I don't think this is the correct design of the OVS library
for our applications. OVS JSON is just another bidirectional
management protocol like OF. So I prefer to implement what we do for
OF, that is, keep a conneciton and convert our OVS JSON Python objects
to the wire-format data structures and vise versa.

However, this is a temporary solution and it turned out that our
Quantum application doesn't need 'monitor' OVS feature so Ryu doesn't
need to keep the connection with OVS db. The current design is fine by
me if the unused parts are dropped.

On Sun, 14 Oct 2012 13:49:22 +0900
Isaku Yamahata <[email protected]> wrote:

> On Sat, Oct 13, 2012 at 05:37:05AM +0900, FUJITA Tomonori wrote:
>> On Fri, 12 Oct 2012 19:43:49 +0900
>> Isaku Yamahata <[email protected]> wrote:
>> 
>> > On Fri, Oct 12, 2012 at 07:39:22AM +0900, FUJITA Tomonori wrote:
>> >> On Thu, 11 Oct 2012 17:17:42 +0900
>> >> Isaku Yamahata <[email protected]> wrote:
>> >> 
>> >> > Signed-off-by: Isaku Yamahata <[email protected]>
>> >> > ---
>> >> >  ryu/lib/ovs/vsctl.py | 1601 
>> >> > ++++++++++++++++++++++++++++++++++++++++++++++++++
>> >> >  1 file changed, 1601 insertions(+)
>> >> >  create mode 100644 ryu/lib/ovs/vsctl.py
>> >> 
>> >> Can we have _only_ what are necessary for GRE app?
>> > 
>> > Will give it a try.
>> 
>> I meant that why you reinvent vsctl? the bridge code can directly use
>> the python library? Why we need the cache code in the vsctl code?
> 
> Because we need python version of
> 'vsctl list-ports/add-port/del-port/set/get/find/'.

This can't be the reason why we have to reimplenent vsctl in Python in
the same way.

What we need is a wrapper of OVS IDL, which is handy for our
application. For example, why this includes vsctl' db commands? This
library is supposed to be handly. We need to provide proper Python
classes and methods for any operations that our application needs.

Also I'm not sure having separate db_client.py. Can we have OVS
library for our application instead of reinventing vsctl with some
other ovs stuff?

> - It's not so simple to manipulate ovsdb in transactional way. OVS db
>   binding(both C and python) is designed such that transaction abort needs
>   to be handed by client. Python couter part is also necessary.
> 
> - cache code.
>   It is necessary to find out if a given port is on a given bridge due
>   to vswitch db schema. It needs to build a tree from bridge table, to port
>   table and interface table.

This is not my question. Every time vsctl is called, it gets all the
data from db and creates python objects representing the config in db,
then operates on it. Why we can't just do several JSON
request/response to find a port? I guess that easier for some
operations to have Python objects rather than sending a bunch of
JSONs.

>   I also found that quantum_adapter doesn't work well. I put some work around

I'm not sure that we discussed this off-line. What 'doesn't work well'
exaclty means?

>   into it for now. It assumes that single ovsdb has a single ovs bridge. But
>   it's not correct. Now quantum-agent creates br-int, br-ex. And other ovs 
>   bridge depending on configuration.
>   But I don't see easy fix for that, and think the right fix would be to 
>   create the tree of bridge-port-interface
>
> - layering bridge and vsctl
>   In long term, OF-config would be supported.
>   I envisage something like bridge-ovsdb and bridge-ofconfig.
> 
> -- 
> yamahata
> 
> ------------------------------------------------------------------------------
> Don't let slow site performance ruin your business. Deploy New Relic APM
> Deploy New Relic app performance management and know exactly
> what is happening inside your Ruby, Python, PHP, Java, and .NET app
> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
> http://p.sf.net/sfu/newrelic-dev2dev
> _______________________________________________
> Ryu-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/ryu-devel

------------------------------------------------------------------------------
LogMeIn Central: Instant, anywhere, Remote PC access and management.
Stay in control, update software, and manage PCs from one command center
Diagnose problems and improve visibility into emerging IT issues
Automate, monitor and manage. Do more in less time with Central
http://p.sf.net/sfu/logmein12331_d2d
_______________________________________________
Ryu-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ryu-devel

Reply via email to