Open Stack

We had this same issue with the dhcp-agent. Code was added that paralleled
the initial sync here: https://review.openstack.org/#/c/28914/  that made
things a good bit faster if I remember correctly.  Might be worth doing
something similar for the l3-agent.

Best,

Aaron


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

>
>
>
> 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
>>>
>>
>>
>
> _______________________________________________
> 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/4aa55060/attachment.html>