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