OK. I will.
Ofer.
On Fri, Apr 1, 2016 at 6:31 PM Ben Pfaff wrote:
> On Mon, Mar 28, 2016 at 06:25:51AM +, Ofer Ben-Yacov wrote:
> > I understand that you met Ayal for a short talk during ONS.
> > From what he told me I think there might be some misunderstanding so I
> > would like to make i
On Mon, Mar 28, 2016 at 06:25:51AM +, Ofer Ben-Yacov wrote:
> I understand that you met Ayal for a short talk during ONS.
> From what he told me I think there might be some misunderstanding so I
> would like to make it clear what the intent here is.
> First, in case I did not explain it clearly
Hi Ben,
I understand that you met Ayal for a short talk during ONS.
From what he told me I think there might be some misunderstanding so I
would like to make it clear what the intent here is.
First, in case I did not explain it clearly before, I do *not* mean that
the right sequence is "connect ->
Hi Ben,
I'm still waiting for you response.
Do you see the reason for the current usage of IDL, where Neutron and my
patch get the schema from the server, or do you insist that the schema will
be read from a file?
I do think that if Neutron is using is like that and I took this approach
too than
Actually, SchemaHelper supports both ways: getting the schema from the
server or read it from file (schema_json / location parameters). Neutron
took the first approach probably because they wanted all the tables anyway.
If we want to keep supporting getting the schema from the server, than my
cha
That's not how the Python version of the IDL is meant to be used.
SchemaHelper operates on the schema that the client *wants*, not on the
schema that the database server *has*. That's why it reads the schema
from a local disk file by default. If Neutron does something else then
it should probably
Take a loot at the contractor of IDL:
...
def __init__(self, remote, schema):
...
You can see that it gets schema as a parameter, which is actually
SchemaHelper object:
...
assert isinstance(schema, SchemaHelper)
...
This object holds the schema in a json string (schema_json) until you will
c
On Wed, Feb 24, 2016 at 08:39:02AM +, Ofer Ben-Yacov wrote:
> The current implementation IDL is:
> 1. connects to the OVSDB
> 2. get the schema and
> 3. disconnect
> 4. connect again to work with the OVSDB server.
I don't understand--where do you see that behavior? I can't spot it
anywhere.
The current implementation IDL is:
1. connects to the OVSDB
2. get the schema and
3. disconnect
4. connect again to work with the OVSDB server.
You can still work like that, if you want, by not sending session object to
the IDL init function:
def __init__(self, remote, schema, session=None):
...
I spent some time looking this over, just now, and I'm a bit confused.
It's clear that the python implementation of PassiveStream did not
support TCP. Great, the patch adds that. If the patch just added that,
I'd be happy, I'd just commit it.
What I don't understand is why other changes are nee
From: Ofer Ben-Yacov
Currently the IDL does not support passive TCP connection,
i.e. when the OVSDB connects to its manager.
This patch enables IDL to use an already-open session
(the one which was previously used for retrieving the db schema).
In addition, it enables IDL to go back to "listen m
11 matches
Mail list logo
