[openstack-dev] [neutron][rootwrap] Performance considerations, sudo?

Joe Gordon joe.gordon0 at gmail.com
Tue Mar 11 00:07:46 UTC 2014


On Mon, Mar 10, 2014 at 3:57 PM, Joe Gordon <joe.gordon0 at gmail.com> wrote:

> I looked into the python to C options and haven't found anything promising
> yet.
>
>
> I tried Cython, and RPython, on a trivial hello world app, but git similar
> startup times to standard python.
>
> The one thing that did work was adding a '-S' when starting python.
>
>        -S     Disable the import of the module site and the site-dependent
> manipulations of sys.path that it entails.
>

Using 'python -S' didn't appear to help in devstack

#!/usr/bin/python -S
# PBR Generated from u'console_scripts'

import sys
import site
site.addsitedir('/mnt/stack/oslo.rootwrap/oslo/rootwrap')




>
> I am not sure if we can do that for rootwrap.
>
>
> jogo at dev:~/tmp/pypy-2.2.1-src$ time ./tmp-c
> hello world
>
> real    0m0.021s
> user    0m0.000s
> sys     0m0.020s
> jogo at dev:~/tmp/pypy-2.2.1-src$ time ./tmp-c
> hello world
>
> real    0m0.021s
> user    0m0.000s
> sys     0m0.020s
> jogo at dev:~/tmp/pypy-2.2.1-src$ time python -S ./tmp.py
> hello world
>
> real    0m0.010s
> user    0m0.000s
> sys     0m0.008s
>
> jogo at dev:~/tmp/pypy-2.2.1-src$ time python -S ./tmp.py
> hello world
>
> real    0m0.010s
> user    0m0.000s
> sys     0m0.008s
>
>
>
> On Mon, Mar 10, 2014 at 3:26 PM, Miguel Angel Ajo Pelayo <
> mangelajo at redhat.com> wrote:
>
>> Hi Carl, thank you, good idea.
>>
>> I started reviewing it, but I will do it more carefully tomorrow morning.
>>
>>
>>
>> ----- Original Message -----
>> > All,
>> >
>> > I was writing down a summary of all of this and decided to just do it
>> > on an etherpad.  Will you help me capture the big picture there?  I'd
>> > like to come up with some actions this week to try to address at least
>> > part of the problem before Icehouse releases.
>> >
>> > https://etherpad.openstack.org/p/neutron-agent-exec-performance
>> >
>> > Carl
>> >
>> > On Mon, Mar 10, 2014 at 5:26 AM, Miguel Angel Ajo <majopela at redhat.com>
>> > wrote:
>> > > Hi Yuri & Stephen, thanks a lot for the clarification.
>> > >
>> > > I'm not familiar with unix domain sockets at low level, but , I wonder
>> > > if authentication could be achieved just with permissions (only users
>> in
>> > > group "neutron" or group "rootwrap" accessing this service.
>> > >
>> > > I find it an interesting alternative, to the other proposed
>> solutions, but
>> > > there are some challenges associated with this solution, which could
>> make
>> > > it
>> > > more complicated:
>> > >
>> > > 1) Access control, file system permission based or token based,
>> > >
>> > > 2) stdout/stderr/return encapsulation/forwarding to the caller,
>> > >    if we have a simple/fast RPC mechanism we can use, it's a matter
>> > >    of serializing a dictionary.
>> > >
>> > > 3) client side implementation for 1 + 2.
>> > >
>> > > 4) It would need to accept new domain socket connections in green
>> threads
>> > > to
>> > > avoid spawning a new process to handle a new connection.
>> > >
>> > > The advantages:
>> > >    * we wouldn't need to break the only-python-rule.
>> > >    * we don't need to rewrite/translate rootwrap.
>> > >
>> > > The disadvantages:
>> > >   * it needs changes on the client side (neutron + other projects),
>> > >
>> > >
>> > > Cheers,
>> > > Miguel Ángel.
>> > >
>> > >
>> > >
>> > > On 03/08/2014 07:09 AM, Yuriy Taraday wrote:
>> > >>
>> > >> On Fri, Mar 7, 2014 at 5:41 PM, Stephen Gran
>> > >> <stephen.gran at theguardian.com <mailto:stephen.gran at theguardian.com>>
>> > >> wrote:
>> > >>
>> > >>     Hi,
>> > >>
>> > >>     Given that Yuriy says explicitly 'unix socket', I dont think he
>> > >>     means 'MQ' when he says 'RPC'.  I think he just means a daemon
>> > >>     listening on a unix socket for execution requests.  This seems
>> like
>> > >>     a reasonably sensible idea to me.
>> > >>
>> > >>
>> > >> Yes, you're right.
>> > >>
>> > >>     On 07/03/14 12:52, Miguel Angel Ajo wrote:
>> > >>
>> > >>
>> > >>         I thought of this option, but didn't consider it, as It's
>> somehow
>> > >>         risky to expose an RPC end executing priviledged (even
>> filtered)
>> > >>         commands.
>> > >>
>> > >>
>> > >> subprocess module have some means to do RPC securely over UNIX
>> sockets.
>> > >> I does this by passing some token along with messages. It should be
>> > >> secure because with UNIX sockets we don't need anything stronger
>> since
>> > >> MITM attacks are not possible.
>> > >>
>> > >>         If I'm not wrong, once you have credentials for messaging,
>> you can
>> > >>         send messages to any end, even filtered, I somehow see this
>> as a
>> > >>         higher
>> > >>         risk option.
>> > >>
>> > >>
>> > >> As Stephen noted, I'm not talking about using MQ for RPC. Just some
>> > >> local UNIX socket with very simple RPC over it.
>> > >>
>> > >>         And btw, if we add RPC in the middle, it's possible that all
>> those
>> > >>         system call delays increase, or don't decrease all it'll be
>> > >>         desirable.
>> > >>
>> > >>
>> > >> Every call to rootwrap would require the following.
>> > >>
>> > >> Client side:
>> > >> - new client socket;
>> > >> - one message sent;
>> > >> - one message received.
>> > >>
>> > >> Server side:
>> > >> - accepting new connection;
>> > >> - one message received;
>> > >> - one fork-exec;
>> > >> - one message sent.
>> > >>
>> > >> This looks like way simpler than passing through sudo and rootwrap
>> that
>> > >> requires three exec's and whole lot of configuration files opened and
>> > >> parsed.
>> > >>
>> > >> --
>> > >>
>> > >> Kind regards, Yuriy.
>> > >>
>> > >>
>> > >> _______________________________________________
>> > >> OpenStack-dev mailing list
>> > >> OpenStack-dev at lists.openstack.org
>> > >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> > >>
>> > >
>> > > _______________________________________________
>> > > OpenStack-dev mailing list
>> > > OpenStack-dev at lists.openstack.org
>> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >
>> > _______________________________________________
>> > OpenStack-dev mailing list
>> > OpenStack-dev at lists.openstack.org
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >
>>
>> _______________________________________________
>> 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/20140310/d0986f25/attachment.html>


More information about the OpenStack-dev mailing list