[ovs-dev] [PATCH v2] ovsdb: implement read-only remote connection type

Lance Richardson lrichard at redhat.com
Tue Oct 18 21:16:39 UTC 2016


> From: "Ben Pfaff" <blp at ovn.org>
> To: "Lance Richardson" <lrichard at redhat.com>
> Cc: dev at openvswitch.org, azhou at ovn.org, nusiddiq at redhat.com, bschanmu at redhat.com, jpettit at ovn.org, russell at ovn.org
> Sent: Monday, October 17, 2016 2:35:22 PM
> Subject: Re: [PATCH v2] ovsdb: implement read-only remote connection type
> 
> On Fri, Oct 14, 2016 at 02:05:54PM -0400, Lance Richardson wrote:
> > This change set adds a new optional access-type specifier to
> > remote connection descriptors for ovsdb-server.
> > 
> > Examples:
> >     --remote=ptcp:ro:0:192.168.0.10
> >     --remote=punix:ro:asocket.sock
> >     --remote=pssl:ro:0:192.168.0.10
> >     --remote=tcp:ro:192.168.0.99:4444
> >     --remote=unix:ro:asocket.sock
> >     --remote=ssl:ro:192.168.0.10:4444
> > 
> > Operations that would alter the state of the database are not
> > permitted on connections for which the "ro" access-type is specified.
> > 
> > Signed-off-by: Lance Richardson <lrichard at redhat.com>
> 
> I'm nervous about this means of configuration for a couple of reasons.
> 
> First, it looks like a layering violation.  --remote specifies the L3
> and L4 information to connect to a remote database server, in a form
> used by OVS in other places too to specify an L3 and L4 (for example, it
> is also used to specify a remote OpenFlow switch or controller).  Adding
> extra specifiers in the middle that only apply to a particular higher
> level protocol does not seem graceful.  It's better to add these extra
> specifiers at a higher level too.
> 
> Second, it doesn't generalize well.  If we need additional OVSDB-level
> specifiers later, then it looks like using this technique they'd also
> have to be added at each of the stream protocol implementations.  It's
> better to have a single implementation.
> 
> I suggest that, instead, we do something based on ovsdb-server's support
> for remotes that come from the database.  Take a look at the "db:" form
> for the --remote option described in ovsdb-server(1).  It offers support
> for a number of configuration options that aren't available via the
> command line, via columns in the database table.  It would be natural to
> make it support a "read_only" configuration option column as well.
> Once we have that, we can think about how to support configuring these
> kinds of options for remotes added through the command line instead of
> through the database table.  One could, for example, add a command-line
> option corresponding to each configuration column, with some kind of
> convention such as the option affects the remote specified in the most
> recent --remote option.  There are other possibilities too, of course.
> 
> Thanks,
> 
> Ben.
> 

I had a pretty good idea that the configuration method would be controversial,
but figured it was better to start somewhere (anywhere) than not start at all.

For the db method, adding a "read only" column makes sense and would match
up nicely with the max_backoff and inactivity_probe columns that are already
present.

For the command line, I wonder if we could support something like:

    --remote=ptcp:0:192.168.0.10,read_only=true

This could also be applied to other existing and future per-connection
configuration options, e.g.:

    --remote=ptcp:0:192.168.0.10,max_backoff=1000,inactivity_probe=5000

Would that be more palatable?

Thanks,

    Lance



More information about the dev mailing list