> Sent: Wednesday, September 09, 2015 at 2:33 PM > From: "Sean Dague" <s...@dague.net> > To: "OpenStack Development Mailing List (not for usage questions)" > <openstack-dev@lists.openstack.org> > Subject: Re: [openstack-dev] [rootwrap] rootwrap and libraries - RFC > > On 09/09/2015 02:55 PM, Robert Collins wrote: > > On 10 September 2015 at 06:45, Matt Riedemann > > <mrie...@linux.vnet.ibm.com> wrote: > >> > > > >> The problem with the static file paths in rootwrap.conf is that we don't > >> know where those other library filter files are going to end up on the > >> system when the library is installed. We could hard-code nova's > >> rootwrap.conf filter_path to include "/etc/os-brick/rootwrap.d" but then > >> that means the deploy/config management tooling that installing this stuff > >> needs to copy that directory structure from the os-brick install location > >> (which we're finding non-deterministic, at least when using data_files with > >> pbr) to the target location that rootwrap.conf cares about. > >> > >> That's why we were proposing adding things to rootwrap.conf that > >> oslo.rootwrap can parse and process dynamically using the resource access > >> stuff in pkg_resources, so we just say 'I want you to load the > >> os-brick.filters file from the os-brick project, thanks.'. > > > > So, I realise thats a bit sucky. My suggestion would be to just take > > the tactical approach of syncing things into each consuming tree - and > > dogpile onto the privsep daemon asap. > > syncing things to the consuming tree means that you've now coupled > upgrade of os-brick, cinder, and nova to be at the same time. Because > the code to use the filters is in os-brick, but the filters are in > cinder and nova. > > That's exactly the opposite direction from where we'd like to move. We > did that work around for Liberty, but that nearly completely makes > os-brick pointless if it now means cinder and nova must be in lockstep > all the time. > > > privsep is the outcome of Gus' experiments with having a Python API to > > talk a richer language than shell command lines to a privileged > > daemon, with one (or more) dedicated daemon processes per server > > process. It avoids all of the churn and difficulties in mapping > > complex things through the command line (none of our rootwrap files > > are actually secure). And its massively lower latency and better > > performing. > > > > https://review.openstack.org/#/c/204073/ > > If someone else wants to go down this path that's fine. I feel like > that's not an answer to the question at all, because it says that > instead of moving forward with a decoupling mechanism (and we want to do > this kind of library approach in the nova/neutron interaction next > cycle, so this isn't a one off) we have to go into a holding pattern and > completely tear up a piece of core infrastructure for N cycles. > > I'm no particular fan of rootwrap, but this suggestion seems pretty non > productive in solving the problems in front of us. Especially given how > deeply the calling interface is embedded in our programs today. > > -Sean > > -- > Sean Dague > http://dague.net > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev