Kyle Mestery <mest...@mestery.com> wrote on 08/01/2016 07:51:42 AM: > From: Kyle Mestery <mest...@mestery.com> > To: Ryan Moats/Omaha/IBM@IBMUS > Cc: Ben Pfaff <b...@ovn.org>, "dev@openvswitch.org" > <dev@openvswitch.org>, Kyle Mestery/Silicon Valley/IBM@IBMUS > Date: 08/01/2016 07:51 AM > Subject: Re: [ovs-dev] Read only versions of the *ctl binaries > > 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 >
When it comes to ovs-appctl, we're looking to set log level access only. Since this doesn't really fit into what I think of when I see "--dry-run", I'm wondering if this variation of the wrapper concept above would do the trick: #! /bin/sh # <code to limit $1 to proper targets> # <code to limit $2 to proper log levels> exec /real/path/to/ovs-appctl vlog/set "$1:$2" _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
