Ben Pfaff <b...@ovn.org> wrote on 07/30/2016 04:06:31 PM: > From: Ben Pfaff <b...@ovn.org> > To: Ryan Moats/Omaha/IBM@IBMUS > Cc: Kyle Mestery/Silicon Valley/IBM@IBMUS, dev@openvswitch.org > Date: 07/30/2016 04:06 PM > Subject: Re: [ovs-dev] Read only versions of the *ctl binaries > > On Sat, Jul 30, 2016 at 02:22:07PM -0500, Ryan Moats wrote: > > Ben Pfaff <b...@ovn.org> wrote on 07/30/2016 01:38:27 PM: > > > > > From: Ben Pfaff <b...@ovn.org> > > > To: Ryan Moats/Omaha/IBM@IBMUS > > > Cc: dev@openvswitch.org > > > Date: 07/30/2016 01:38 PM > > > Subject: Re: [ovs-dev] Read only versions of the *ctl binaries > > > > > > 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? > > > > I'm going to say some of both (and hope that Kyle chimes in here > > with better reasons if I forget something). > > > > The bottom line is the interaction of two requirements for our > > deployments (you can call these bureaucratic, but we've learned > > the hard way that they are *absolute* when operating large > > clouds, so we feel that they are valuable): > > > > 1) That all cloud deployments be "repeatable." > > > > 2) That all necessary telemetry information be collectable for > > problem triage. > > > > The upshot of the first is that an operator at a keyboard can't be > > able to apply a "one-off" state change on a single machine, because > > now the deployment of that machine (and therefore the cloud) is > > "non-repeatable". This practical aspect of this is that we aren't > > going to give anyone access to any of the *ctl commands in their > > current form. > > > > On the other hand, the second means we have to give access to > > the read only portions of all of the *ctl commands because, afaik, > > they are the only things that can read the various state information > > needed for triaging problems. > > > > Now, rather than split the read write and read only portions of the > > *ctl commands apart (because other parts of the community likely > > operate their clouds differently), my thought was just to spin new > > versions that contain just the read only pieces under a new name > > and give our operation folks access to them. But this also explains > > my comment about carrying a local patch - we will *have* to do > > something about this and I'd like the communities eyes on it because > > (a) as I dig through the code, I'm finding places that I'm going to > > question in terms of whether a command is RW or RO and (b) more > > reviewing eyes are always better. > > > > Hopefully the above explains the situation more clearly (and again, > > Kyle, please jump in with more supporting details or other points > > I may have forgotten). > > Can you just install the read/write versions off-$PATH somewhere and > then install > #! /bin/sh > exec /real/path/to/ovs-vsctl --dry-run "$@" > etc.? > > I'm trying to understand the requirements here properly before going any > further.
While the above might work for the commands that support dry-run (i.e. I'd have to test it out to make sure there aren't any holes either way), it still leaves me with how to handle commands like ovs-ofctl and ovs-dpctl that don't currently accept the --dry-run option. When at look at those two, I'm not seeing any simple options jump out at me - and if I'm going to hack two commands, well then .... _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
