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 <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. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev