[ovs-dev] ovn: Improving southbound database security

Lance Richardson lrichard at redhat.com
Fri Oct 21 20:38:43 UTC 2016


> From: "Ben Pfaff" <blp at ovn.org>
> To: "Russell Bryant" <russell at ovn.org>
> Cc: "ovs dev" <dev at openvswitch.org>
> Sent: Friday, October 21, 2016 4:33:33 PM
> Subject: Re: [ovs-dev] ovn: Improving southbound database security
> 
> On Fri, Oct 21, 2016 at 04:10:58PM -0400, Russell Bryant wrote:
> > On Thu, Oct 20, 2016 at 5:52 PM, Han Zhou <zhouhan at gmail.com> wrote:
> > 
> > >
> > > On Thu, Oct 20, 2016 at 11:51 AM, Russell Bryant <russell at ovn.org> wrote:
> > > >
> > > > On Thu, Oct 20, 2016 at 1:47 PM, Ben Pfaff <blp at ovn.org> wrote:
> > > >
> > > > > On Thu, Oct 13, 2016 at 07:32:53PM +0530, Numan Siddique wrote:
> > > > >
> > > > > > 5) Remove support from ovn-controller updating the 'Chassis.hv_cfg'
> > > > > > column and handle the side effect in "--wait=hv" in ovn-nbctl.
> > > > >
> > > > > The ability to wait for hypervisors to catch up is pretty valuable.
> > > I'm
> > > > > not super happy about losing it.
> > > > >
> > > >
> > > > I'm not either.
> > > >
> > > > The only compromise I could come up with was retain it, but document
> > > > that
> > > > it won't work if you run the SB DB in a read-only mode.  That's how
> > > > we'd
> > > > recommend it to be done in production, so the feature would become a
> > > > test-only feature, but then the tests wouldn't be helping ensure we
> > > > only
> > > > read from the sb db otherwise.
> > > >
> > > > --
> > >
> > > Apart from security, I think there is one more benefit of making SB
> > > readonly, at least for short term. It can help deploying in a large scale
> > > environment by sharing SB connections. Assume one SB server can support
> > > 1k
> > > HV connections, we can achieve 10k HVs by 10 slave SB servers, each
> > > replicating all changes of SB from a master node. For this to work, we
> > > need
> > > to make SB readonly to avoid the consensus problem, which I assume will
> > > be
> > > solved by Raft support or etcd, but not very soon.
> > >
> > 
> > That's a really great point.  I hadn't considered this positive side
> > effect.
> 
> I'm OK with losing this ability for now, I think, but I'd like to
> continue thinking about how to get it back later.

Similar to the remote read-only flag, perhaps we could add columns indicating
tables/rows/columns that are writable for each remote.



More information about the dev mailing list