On Tue, Oct 18, 2016 at 05:16:39PM -0400, Lance Richardson wrote: > > 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: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. > > > > 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.
Yes. > 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? Hmm. I'm not super happy with adding a syntax with commas that can't be escaped or quoted. How about adding a --ro-remote option for a read-only remote? It doesn't generalize well either, but it's easy to deal with for now, doesn't have layering violations, doesn't impose any new requirements on the syntax of remotes (e.g. no commas), and it's easy to support later in a deprecated form if we add something more general. Another possibility to make this only configurable through the database. I guess that's OK too. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
