Open Stack

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.

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/

-Rob


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