<div dir="ltr">We had this same issue with the dhcp-agent. Code was added that paralleled the initial sync here: <a href="https://review.openstack.org/#/c/28914/">https://review.openstack.org/#/c/28914/</a>  that made things a good bit faster if I remember correctly.  Might be worth doing something similar for the l3-agent. <div>
<br></div><div>Best, </div><div><br></div><div>Aaron</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Mar 10, 2014 at 5:07 PM, Joe Gordon <span dir="ltr"><<a href="mailto:joe.gordon0@gmail.com" target="_blank">joe.gordon0@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote"><div class="">On Mon, Mar 10, 2014 at 3:57 PM, Joe Gordon <span dir="ltr"><<a href="mailto:joe.gordon0@gmail.com" target="_blank">joe.gordon0@gmail.com</a>></span> wrote:<br>


<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">I looked into the python to C options and haven't found anything promising yet.<div>


<br></div><div><br></div><div>I tried Cython, and RPython, on a trivial hello world app, but git similar startup times to standard python.</div>
<div><br></div><div>The one thing that did work was adding a '-S' when starting python.</div><div><br></div><div><div>       -S     Disable the import of the module site and the site-dependent manipulations of sys.path that it entails.</div>


</div></div></blockquote><div><br></div></div><div>Using 'python -S' didn't appear to help in devstack</div><div><br></div><div><div>#!/usr/bin/python -S</div><div># PBR Generated from u'console_scripts'</div>


<div><br></div><div>import sys</div><div>import site</div><div>site.addsitedir('/mnt/stack/oslo.rootwrap/oslo/rootwrap')</div><div><br></div></div><div><div class="h5"><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">


<div dir="ltr"><div>
</div><div><br></div><div>I am not sure if we can do that for rootwrap.</div><div><br></div><div><br></div><div><div>jogo@dev:~/tmp/pypy-2.2.1-src$ time ./tmp-c </div><div>hello world</div><div><br></div><div>real    0m0.021s</div>



<div>user    0m0.000s</div><div>sys     0m0.020s</div><div><div>jogo@dev:~/tmp/pypy-2.2.1-src$ time ./tmp-c </div><div>hello world</div><div><br></div><div>real    0m0.021s</div><div>user    0m0.000s</div><div>sys     0m0.020s</div>



<div>jogo@dev:~/tmp/pypy-2.2.1-src$ time python -S ./tmp.py</div><div>hello world</div><div><br></div><div>real    0m0.010s</div><div>user    0m0.000s</div><div>sys     0m0.008s</div></div><div><br></div><div>jogo@dev:~/tmp/pypy-2.2.1-src$ time python -S ./tmp.py</div>



<div>hello world</div><div><br></div><div>real    0m0.010s</div><div>user    0m0.000s</div><div>sys     0m0.008s</div></div><div><br></div></div><div><div><div class="gmail_extra"><br><br><div class="gmail_quote">

On Mon, Mar 10, 2014 at 3:26 PM, Miguel Angel Ajo Pelayo <span dir="ltr"><<a href="mailto:mangelajo@redhat.com" target="_blank">mangelajo@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Hi Carl, thank you, good idea.<br>
<br>
I started reviewing it, but I will do it more carefully tomorrow morning.<br>
<div><div><br>
<br>
<br>
----- Original Message -----<br>
> All,<br>
><br>
> I was writing down a summary of all of this and decided to just do it<br>
> on an etherpad.  Will you help me capture the big picture there?  I'd<br>
> like to come up with some actions this week to try to address at least<br>
> part of the problem before Icehouse releases.<br>
><br>
> <a href="https://etherpad.openstack.org/p/neutron-agent-exec-performance" target="_blank">https://etherpad.openstack.org/p/neutron-agent-exec-performance</a><br>
><br>
> Carl<br>
><br>
> On Mon, Mar 10, 2014 at 5:26 AM, Miguel Angel Ajo <<a href="mailto:majopela@redhat.com" target="_blank">majopela@redhat.com</a>><br>
> wrote:<br>
> > Hi Yuri & Stephen, thanks a lot for the clarification.<br>
> ><br>
> > I'm not familiar with unix domain sockets at low level, but , I wonder<br>
> > if authentication could be achieved just with permissions (only users in<br>
> > group "neutron" or group "rootwrap" accessing this service.<br>
> ><br>
> > I find it an interesting alternative, to the other proposed solutions, but<br>
> > there are some challenges associated with this solution, which could make<br>
> > it<br>
> > more complicated:<br>
> ><br>
> > 1) Access control, file system permission based or token based,<br>
> ><br>
> > 2) stdout/stderr/return encapsulation/forwarding to the caller,<br>
> >    if we have a simple/fast RPC mechanism we can use, it's a matter<br>
> >    of serializing a dictionary.<br>
> ><br>
> > 3) client side implementation for 1 + 2.<br>
> ><br>
> > 4) It would need to accept new domain socket connections in green threads<br>
> > to<br>
> > avoid spawning a new process to handle a new connection.<br>
> ><br>
> > The advantages:<br>
> >    * we wouldn't need to break the only-python-rule.<br>
> >    * we don't need to rewrite/translate rootwrap.<br>
> ><br>
> > The disadvantages:<br>
> >   * it needs changes on the client side (neutron + other projects),<br>
> ><br>
> ><br>
> > Cheers,<br>
> > Miguel Ángel.<br>
> ><br>
> ><br>
> ><br>
> > On 03/08/2014 07:09 AM, Yuriy Taraday wrote:<br>
> >><br>
> >> On Fri, Mar 7, 2014 at 5:41 PM, Stephen Gran<br>
> >> <<a href="mailto:stephen.gran@theguardian.com" target="_blank">stephen.gran@theguardian.com</a> <mailto:<a href="mailto:stephen.gran@theguardian.com" target="_blank">stephen.gran@theguardian.com</a>>><br>



> >> wrote:<br>
> >><br>
> >>     Hi,<br>
> >><br>
> >>     Given that Yuriy says explicitly 'unix socket', I dont think he<br>
> >>     means 'MQ' when he says 'RPC'.  I think he just means a daemon<br>
> >>     listening on a unix socket for execution requests.  This seems like<br>
> >>     a reasonably sensible idea to me.<br>
> >><br>
> >><br>
> >> Yes, you're right.<br>
> >><br>
> >>     On 07/03/14 12:52, Miguel Angel Ajo wrote:<br>
> >><br>
> >><br>
> >>         I thought of this option, but didn't consider it, as It's somehow<br>
> >>         risky to expose an RPC end executing priviledged (even filtered)<br>
> >>         commands.<br>
> >><br>
> >><br>
> >> subprocess module have some means to do RPC securely over UNIX sockets.<br>
> >> I does this by passing some token along with messages. It should be<br>
> >> secure because with UNIX sockets we don't need anything stronger since<br>
> >> MITM attacks are not possible.<br>
> >><br>
> >>         If I'm not wrong, once you have credentials for messaging, you can<br>
> >>         send messages to any end, even filtered, I somehow see this as a<br>
> >>         higher<br>
> >>         risk option.<br>
> >><br>
> >><br>
> >> As Stephen noted, I'm not talking about using MQ for RPC. Just some<br>
> >> local UNIX socket with very simple RPC over it.<br>
> >><br>
> >>         And btw, if we add RPC in the middle, it's possible that all those<br>
> >>         system call delays increase, or don't decrease all it'll be<br>
> >>         desirable.<br>
> >><br>
> >><br>
> >> Every call to rootwrap would require the following.<br>
> >><br>
> >> Client side:<br>
> >> - new client socket;<br>
> >> - one message sent;<br>
> >> - one message received.<br>
> >><br>
> >> Server side:<br>
> >> - accepting new connection;<br>
> >> - one message received;<br>
> >> - one fork-exec;<br>
> >> - one message sent.<br>
> >><br>
> >> This looks like way simpler than passing through sudo and rootwrap that<br>
> >> requires three exec's and whole lot of configuration files opened and<br>
> >> parsed.<br>
> >><br>
> >> --<br>
> >><br>
> >> Kind regards, Yuriy.<br>
> >><br>
> >><br>
> >> _______________________________________________<br>
> >> OpenStack-dev mailing list<br>
> >> <a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
> >> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
> >><br>
> ><br>
> > _______________________________________________<br>
> > OpenStack-dev mailing list<br>
> > <a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
> > <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div></div></div><br></div></div>
<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div>