[ovs-dev] [PATCH 05/13] Cleanly separate IDL annotations from OVSDB schema information.

Ben Pfaff blp at nicira.com
Tue Jan 26 17:47:04 UTC 2010


On Mon, Jan 25, 2010 at 05:04:14PM -0500, Jesse Gross wrote:
> On Mon, Jan 25, 2010 at 1:18 PM, Ben Pfaff <blp at nicira.com> wrote:
> 
> > Until now, the OVSDB IDL annotations have been glommed together with the
> > schema information in a single file, and then we've used ovsdb-idlc to
> > extract the schema from that file.  This commit reverses the process:
> > the schema and the annotations are stored separately and then glommed
> > together as necessary at build time.
> >
> > This new arrangement has a few advantages:
> >
> >    - We can now easily have multiple different sets of IDL annotations
> >      for a single OVSDB schema.  For example, some users may not need
> >      access to columns that other users do.
> >
> >    - Bugs in ovsdb-idlc cannot screw up the underlying schema (as shown
> >      by a recent commit).
> >
> 
> The code looks fine but I can't say that I'm too thrilled about this.  It
> seems to me that by separating the two components into different files,
> the likelihood of errors actually increases since it is easier that one
> might be updated without the other or other mistakes.

This is somewhat true, of course, but the Python syntax makes it harder
than it might be because, for example, if you try to add an annotation
to a column or a table and get the name wrong then you will get a Python
backtrace.

This commit is actually an intermediate step.  My final goal is to merge
almost everything currently in the annotations into the schema itself
(with obvious exception such as, e.g., the header file name).  I hope to
do that within a week or two.

> The first advantage is obviously true, though it seems unlikely that we will
> actually use it.

I intend to use it at some point, in particular to make ovs-vsctl,
ovs-vswitchd, and possibly ovs-brcompatd use different sets of columns.
In particular ovs-brcompatd and ovs-vsctl don't care at all about many
columns in most cases and so it's a waste to always send them across the
connection and keep them up to date over time.

> As for the second advantage, wasn't the problem caused by an error in the
> IDL file, not a bug in the converter?  

It was an error in the schema subset of the IDL file.

> Personally I would prefer that ovsdb-idlc just be stricter about what
> it lets through.

I think that's a good thing to do, too, but since with this commit any
errors in the schema will be found by ovsdb-tool at "make check" time,
it doesn't seem paramount.





More information about the dev mailing list