On Fri, Oct 21, 2016 at 04:38:43PM -0400, Lance Richardson wrote: > > From: "Ben Pfaff" <b...@ovn.org> > > To: "Russell Bryant" <russ...@ovn.org> > > Cc: "ovs dev" <dev@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 <zhou...@gmail.com> wrote: > > > > > > > > > > > On Thu, Oct 20, 2016 at 11:51 AM, Russell Bryant <russ...@ovn.org> > > > > wrote: > > > > > > > > > > On Thu, Oct 20, 2016 at 1:47 PM, Ben Pfaff <b...@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.
That's a logical extension to the design and I agree that it might be worth pursuing. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
