[openstack-dev] Python overhead for rootwrap

Mike Wilson geekinutah at gmail.com
Thu Jul 25 20:40:30 UTC 2013


In my opinion:

1. Stop using rootwrap completely and get strong argument checking support
into sudo (regex).
2. Some sort of long lived rootwrap process, either forked by the service
that want's to shell out or a general purpose rootwrapd type thing.

I prefer #1 because it's surprising that sudo doesn't do this type of thing
already. It _must_ be something that everyone wants. But #2 may be quicker
and easier to implement, my $.02.

-Mike Wilson


On Thu, Jul 25, 2013 at 2:21 PM, Joe Gordon <joe.gordon0 at gmail.com> wrote:

> Hi All,
>
> We have recently hit some performance issues with nova-network.  It turns
> out the root cause of this was we do roughly 20 rootwrapped shell commands,
> many inside of global locks. (https://bugs.launchpad.net/oslo/+bug/1199433
> )
>
> It turns out starting python itself, has a fairly significant overhead
> when compared to the run time of many of the binary commands we execute.
>
> For example:
>
>  $ time python -c "print 'test'"
> test
>
> real 0m0.023s
> user 0m0.016s
> sys 0m0.004s
>
>
> $ time ip a
> <...>
>
> real 0m0.003s
> user 0m0.000s
> sys 0m0.000s
>
>
> While we have removed the extra overhead of using entry points, we are now
> hitting the overhead of just shelling out to python.
>
>
> While there are many possible ways to reduce this issue, such as reducing
> the number of rootwrapped calls and making locks finer grain, I think its
> worth exploring alternates to the current rootwrap model.
>
> Any ideas?  I am sending this email out to get the discussion started.
>
>
> best,
> Joe Gordon
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130725/f8b9edc0/attachment.html>


More information about the OpenStack-dev mailing list