> From: "Ben Pfaff" <b...@ovn.org>
> To: "Lance Richardson" <lrich...@redhat.com>
> Cc: dev@openvswitch.org, az...@ovn.org, nusid...@redhat.com, 
> bscha...@redhat.com, jpet...@ovn.org, russ...@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:
> >     --remote=punix:ro:asocket.sock
> >     --remote=pssl:ro:0:
> >     --remote=tcp:ro:
> >     --remote=unix:ro:asocket.sock
> >     --remote=ssl:ro:
> > 
> > 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 <lrich...@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

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


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


Would that be more palatable?


dev mailing list

Reply via email to