Open Stack

> Sent: Wednesday, September 09, 2015 at 2:33 PM
> From: "Sean Dague" <sean at dague.net>
> To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at 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
> > <mriedem at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>