Open Stack

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