On Sun, Jul 31, 2016 at 7:40 PM, Ryan Moats <rmo...@us.ibm.com> wrote: > Ben Pfaff <b...@ovn.org> wrote on 07/31/2016 11:53:15 AM: > >> From: Ben Pfaff <b...@ovn.org> >> To: Ryan Moats/Omaha/IBM@IBMUS >> Cc: dev@openvswitch.org, Kyle Mestery/Silicon Valley/IBM@IBMUS >> Date: 07/31/2016 11:53 AM >> Subject: Re: [ovs-dev] Read only versions of the *ctl binaries >> >> On Sat, Jul 30, 2016 at 09:25:59PM -0500, Ryan Moats wrote: >> > 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 .... >> >> Those two don't have a --dry-run option. I think adding an option like >> that for them would be just fine for upstream; I'd have no objection. >> It's whether it makes sense for upstream to actually build two different >> binaries that I'm uncertain about. > > Ok, I suspect that's doable fairly quickly, and I will also sit down with > the binaries that have --dry-run to verify that there aren't any holes.
As I was not checking email all weekend, it appears this thread has reached a potential conclusion. I'm happy with "--dry-run" added to the commands currently lacking it, and that would allow us to do what we need as well. Thanks! Kyle > _______________________________________________ > dev mailing list > dev@openvswitch.org > http://openvswitch.org/mailman/listinfo/dev _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
