On Fri, Jul 29, 2016 at 05:35:31PM -0500, Ryan Moats wrote: > Ben Pfaff <b...@ovn.org> wrote on 07/29/2016 05:27:29 PM: > > > From: Ben Pfaff <b...@ovn.org> > > To: Ryan Moats/Omaha/IBM@IBMUS > > Cc: dev@openvswitch.org > > Date: 07/29/2016 05:27 PM > > Subject: Re: [ovs-dev] Read only versions of the *ctl binaries > > > > On Fri, Jul 29, 2016 at 04:11:00PM -0500, Ryan Moats wrote: > > > > > > We just received a new operational requirement that we have > > > to restrict access to all binaries that provide RW access to > > > infrastructure components, but yet still have the ability to > > > read current state from the infrastructure. > > > > > > For OVN/OVS, this means we won't be able to use the following > > > binaries in our production environment to read current state: > > > ovs-vsctl, ovs-dpctl, ovs-ofctl, ovs-appctl, ovn-nbctl, and > > > ovn-sbctl. > > > > > > I'm thinking of meeting this by creating new binaries > > > ovs-vsread, ovs-dpread, ovs-ofread, ovs-appread, ovn-nbread, > > > and ovn-sbread that would include the show, list, and search > > > commands from their RW brethren, but omit the various add > > > and del commands. > > > > > > Before I start crafting code, I wanted to see if folks can > > > think of a simpler way of meeting this new requirement... > > > > You could hard-code the 'dry_run' variable to true. > > > > Yes, that will certainly be quicker, and I can couple that with > some Makefile magic to allow the same source code to produce > both the *ctl and *read binaries (which lowers future > maintenance costs too)... > > The $64K question for the community is this idea acceptable? > The tl;dr; is that I'd rather not carry this type of change > around as a local patch, but I will if I have to...
I'm not yet convinced that this is useful. Is it a valuable feature or a bureaucratic requirement? _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
