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

[Ben Pfaff]

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.