Open Stack

On 10 September 2015 at 07:33, Sean Dague <sean at dague.net> wrote:
> 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.

If it not helpful, its not helpful - sorry. My perspective was that we
want privsep in deployments for M, so if the brick code can move to
privsep during M, there's only one cycle during which rootwrap filters
may need to be adjusted.

> 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.

AIUI the case here is that there is a library, and you call that.
Which means the calling interface of rootwrap isn't broadly at issue -
we only need to migrate the calls w/in brick to solve the issue.

Anyhow, as you say, it may not be helpful - so I'll not kibbitz, EOF
:). If I do have thoughts on the rootwrap thing specifically I'll
write a separate reply.

-Rob


-- 
Robert Collins <rbtcollins at hp.com>
Distinguished Technologist
HP Converged Cloud