<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Mar 19, 2014 at 9:25 AM, Miguel Angel Ajo <span dir="ltr"><<a href="mailto:majopela@redhat.com" target="_blank">majopela@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
An advance on the changes that it's requiring to have a<br>
py->c++ compiled rootwrap as a mitigation POC for havana/icehouse.<br>
<br>
<a href="https://github.com/mangelajo/shedskin.rootwrap/commit/e4167a6491dfbc71e2d0f6e28ba93bc8a1dd66c0" target="_blank">https://github.com/mangelajo/<u></u>shedskin.rootwrap/commit/<u></u>e4167a6491dfbc71e2d0f6e28ba93b<u></u>c8a1dd66c0</a><br>
<br>
The current translation output is included.<br>
<br>
It looks like doable (almost killed 80% of the translation problems),<br>
but there are two big stones:<br>
<br>
1) As Joe said, no support for Subprocess (we're interested in popen),<br>
I'm using a dummy os.system() for the test.<br>
<br>
2) No logging support.<br>
<br>
I'm not sure on how complicated could be getting those modules implemented for shedkin.</blockquote><div><br></div><div>Before sorting out of we can get those working under shedskin, any preliminary performance numbers from neutron when using this?</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5"><br>
<br>
On 03/18/2014 09:14 AM, Miguel Angel Ajo wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi Joe, thank you very much for the positive feedback,<br>
<br>
I plan to spend a day during this week on the shedskin-compatibility<br>
for rootwrap (I'll branch it, and tune/cut down as necessary) to make<br>
it compile under shedskin [1] : nothing done yet.<br>
<br>
It's a short-term alternative until we can have a rootwrap agent,<br>
together with it's integration in neutron (for Juno). As, for the<br>
compiled rootwrap, if it works, and if it does look good (security wise)<br>
then we'd have a solution for Icehouse/Havana.<br>
<br>
help in [1] is really welcome ;-) I'm available in #openstack-neutron<br>
as 'ajo'.<br>
<br>
Best regards,<br>
Miguel Ángel.<br>
<br>
[1] <a href="https://github.com/mangelajo/shedskin.rootwrap" target="_blank">https://github.com/mangelajo/<u></u>shedskin.rootwrap</a><br>
<br>
On 03/18/2014 12:48 AM, Joe Gordon wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
<br>
On Tue, Mar 11, 2014 at 1:46 AM, Miguel Angel Ajo Pelayo<br>
<<a href="mailto:mangelajo@redhat.com" target="_blank">mangelajo@redhat.com</a> <mailto:<a href="mailto:mangelajo@redhat.com" target="_blank">mangelajo@redhat.com</a>>> wrote:<br>
<br>
<br>
I have included on the etherpad, the option to write a sudo<br>
plugin (or several), specific for openstack.<br>
<br>
<br>
And this is a test with shedskin, I suppose that in more complicated<br>
dependecy scenarios it should perform better.<br>
<br>
[majopela@redcylon tmp]$ cat <<EOF >test.py<br>
> import sys<br>
> print "hello world"<br>
> sys.exit(0)<br>
> EOF<br>
<br>
[majopela@redcylon tmp]$ time python test.py<br>
hello world<br>
<br>
real 0m0.016s<br>
user 0m0.015s<br>
sys 0m0.001s<br>
<br>
<br>
<br>
This looks very promising!<br>
<br>
A few gotchas:<br>
<br>
* Very limited library support<br>
<a href="https://code.google.com/p/shedskin/wiki/docs#Library_Limitations" target="_blank">https://code.google.com/p/<u></u>shedskin/wiki/docs#Library_<u></u>Limitations</a><br>
* no logging<br>
* no six<br>
* no subprocess<br>
<br>
* no *args support<br>
*<br>
<a href="https://code.google.com/p/shedskin/wiki/docs#Python_Subset_Restrictions" target="_blank">https://code.google.com/p/<u></u>shedskin/wiki/docs#Python_<u></u>Subset_Restrictions</a><br>
<br>
that being said I did a quick comparison with great results:<br>
<br>
$ cat tmp.sh<br>
#!/usr/bin/env bash<br>
echo $0 $@<br>
ip a<br>
<br>
$ time ./tmp.sh foo bar> /dev/null<br>
<br>
real 0m0.009s<br>
user 0m0.003s<br>
sys 0m0.006s<br>
<br>
<br>
<br>
$ cat tmp.py<br>
#!/usr/bin/env python<br>
import os<br>
import sys<br>
<br>
print sys.argv<br>
print os.system("ip a")<br>
<br>
$ time ./tmp.py foo bar > /dev/null<br>
<br>
min:<br>
real 0m0.016s<br>
user 0m0.004s<br>
sys 0m0.012s<br>
<br>
max:<br>
real 0m0.038s<br>
user 0m0.016s<br>
sys 0m0.020s<br>
<br>
<br>
<br>
shedskin tmp.py && make<br>
<br>
<br>
$ time ./tmp foo bar > /dev/null<br>
<br>
real 0m0.010s<br>
user 0m0.007s<br>
sys 0m0.002s<br>
<br>
<br>
<br>
Based in these results I think a deeper dive into making rootwrap<br>
supportshedskin is worthwhile.<br>
<br>
<br>
<br>
<br>
<br>
[majopela@redcylon tmp]$ shedskin test.py<br>
*** SHED SKIN Python-to-C++ Compiler 0.9.4 ***<br>
Copyright 2005-2011 Mark Dufour; License GNU GPL version 3 (See<br>
LICENSE)<br>
<br>
[analyzing types..]<br>
******************************<u></u>**100%<br>
[generating c++ code..]<br>
[elapsed time: 1.59 seconds]<br>
[majopela@redcylon tmp]$ make<br>
g++ -O2 -march=native -Wno-deprecated -I.<br>
-I/usr/lib/python2.7/site-<u></u>packages/shedskin/lib /tmp/test.cpp<br>
/usr/lib/python2.7/site-<u></u>packages/shedskin/lib/sys.cpp<br>
/usr/lib/python2.7/site-<u></u>packages/shedskin/lib/re.cpp<br>
/usr/lib/python2.7/site-<u></u>packages/shedskin/lib/builtin.<u></u>cpp -lgc<br>
-lpcre -o test<br>
[majopela@redcylon tmp]$ time ./test<br>
hello world<br>
<br>
real 0m0.003s<br>
user 0m0.000s<br>
sys 0m0.002s<br>
<br>
<br>
----- Original Message -----<br>
> We had this same issue with the dhcp-agent. Code was added that<br>
paralleled<br>
> the initial sync here: <a href="https://review.openstack.org/#/c/28914/" target="_blank">https://review.openstack.org/#<u></u>/c/28914/</a><br>
that made<br>
> things a good bit faster if I remember correctly. Might be worth<br>
doing<br>
> something similar for the l3-agent.<br>
><br>
> Best,<br>
><br>
> Aaron<br>
><br>
><br>
> On Mon, Mar 10, 2014 at 5:07 PM, Joe Gordon <<br>
<a href="mailto:joe.gordon0@gmail.com" target="_blank">joe.gordon0@gmail.com</a> <mailto:<a href="mailto:joe.gordon0@gmail.com" target="_blank">joe.gordon0@gmail.com</a>> > wrote:<br>
><br>
><br>
><br>
><br>
><br>
><br>
> On Mon, Mar 10, 2014 at 3:57 PM, Joe Gordon <<br>
<a href="mailto:joe.gordon0@gmail.com" target="_blank">joe.gordon0@gmail.com</a> <mailto:<a href="mailto:joe.gordon0@gmail.com" target="_blank">joe.gordon0@gmail.com</a>> > wrote:<br>
><br>
><br>
><br>
> I looked into the python to C options and haven't found anything<br>
promising<br>
> yet.<br>
><br>
><br>
> I tried Cython, and RPython, on a trivial hello world app, but<br>
git similar<br>
> startup times to standard python.<br>
><br>
> The one thing that did work was adding a '-S' when starting<br>
python.<br>
><br>
> -S Disable the import of the module site and the site-dependent<br>
manipulations<br>
> of sys.path that it entails.<br>
><br>
> Using 'python -S' didn't appear to help in devstack<br>
><br>
> #!/usr/bin/python -S<br>
> # PBR Generated from u'console_scripts'<br>
><br>
> import sys<br>
> import site<br>
> site.addsitedir('/mnt/stack/<u></u>oslo.rootwrap/oslo/rootwrap')<br>
><br>
><br>
><br>
><br>
><br>
><br>
> I am not sure if we can do that for rootwrap.<br>
><br>
><br>
> jogo@dev:~/tmp/pypy-2.2.1-src$ time ./tmp-c<br>
> hello world<br>
><br>
> real 0m0.021s<br>
> user 0m0.000s<br>
> sys 0m0.020s<br>
> jogo@dev:~/tmp/pypy-2.2.1-src$ time ./tmp-c<br>
> hello world<br>
><br>
> real 0m0.021s<br>
> user 0m0.000s<br>
> sys 0m0.020s<br>
> jogo@dev:~/tmp/pypy-2.2.1-src$ time python -S ./tmp.py<br>
> hello world<br>
><br>
> real 0m0.010s<br>
> user 0m0.000s<br>
> sys 0m0.008s<br>
><br>
> jogo@dev:~/tmp/pypy-2.2.1-src$ time python -S ./tmp.py<br>
> hello world<br>
><br>
> real 0m0.010s<br>
> user 0m0.000s<br>
> sys 0m0.008s<br>
><br>
><br>
><br>
> On Mon, Mar 10, 2014 at 3:26 PM, Miguel Angel Ajo Pelayo <<br>
> <a href="mailto:mangelajo@redhat.com" target="_blank">mangelajo@redhat.com</a> <mailto:<a href="mailto:mangelajo@redhat.com" target="_blank">mangelajo@redhat.com</a>> > wrote:<br>
><br>
><br>
> Hi Carl, thank you, good idea.<br>
><br>
> I started reviewing it, but I will do it more carefully tomorrow<br>
morning.<br>
><br>
><br>
><br>
> ----- Original Message -----<br>
> > All,<br>
> ><br>
> > I was writing down a summary of all of this and decided to just<br>
do it<br>
> > on an etherpad. Will you help me capture the big picture<br>
there? I'd<br>
> > like to come up with some actions this week to try to address<br>
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.<u></u>org/p/neutron-agent-exec-<u></u>performance</a><br>
> ><br>
> > Carl<br>
> ><br>
> > On Mon, Mar 10, 2014 at 5:26 AM, Miguel Angel Ajo <<br>
<a href="mailto:majopela@redhat.com" target="_blank">majopela@redhat.com</a> <mailto:<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 ,<br>
I wonder<br>
> > > if authentication could be achieved just with permissions<br>
(only users in<br>
> > > group "neutron" or group "rootwrap" accessing this service.<br>
> > ><br>
> > > I find it an interesting alternative, to the other proposed<br>
solutions,<br>
> > > but<br>
> > > there are some challenges associated with this solution,<br>
which could make<br>
> > > it<br>
> > > more complicated:<br>
> > ><br>
> > > 1) Access control, file system permission based or token<br>
based,<br>
> > ><br>
> > > 2) stdout/stderr/return encapsulation/forwarding to the<br>
caller,<br>
> > > if we have a simple/fast RPC mechanism we can use, it's a<br>
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<br>
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<br>
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><br>
<mailto:<a href="mailto:stephen.gran@theguardian.com" target="_blank">stephen.gran@<u></u>theguardian.com</a>> <mailto:<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@<u></u>theguardian.com</a>> >><br>
> > >> wrote:<br>
> > >><br>
> > >> Hi,<br>
> > >><br>
> > >> Given that Yuriy says explicitly 'unix socket', I dont<br>
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<br>
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<br>
somehow<br>
> > >> risky to expose an RPC end executing priviledged (even<br>
filtered)<br>
> > >> commands.<br>
> > >><br>
> > >><br>
> > >> subprocess module have some means to do RPC securely over<br>
UNIX sockets.<br>
> > >> I does this by passing some token along with messages. It<br>
should be<br>
> > >> secure because with UNIX sockets we don't need anything<br>
stronger since<br>
> > >> MITM attacks are not possible.<br>
> > >><br>
> > >> If I'm not wrong, once you have credentials for messaging,<br>
you can<br>
> > >> send messages to any end, even filtered, I somehow see<br>
this as a<br>
> > >> higher<br>
> > >> risk option.<br>
> > >><br>
> > >><br>
> > >> As Stephen noted, I'm not talking about using MQ for RPC.<br>
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<br>
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<br>
rootwrap that<br>
> > >> requires three exec's and whole lot of configuration files<br>
opened and<br>
> > >> parsed.<br>
> > >><br>
> > >> --<br>
> > >><br>
> > >> Kind regards, Yuriy.<br>
> > >><br>
> > >><br>
> > >> ______________________________<u></u>_________________<br>
> > >> OpenStack-dev mailing list<br>
> > >> <a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.<u></u>org</a><br>
<mailto:<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.<u></u>openstack.org</a>><br>
> > >><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>
> > >><br>
> > ><br>
> > > ______________________________<u></u>_________________<br>
> > > OpenStack-dev mailing list<br>
> > > <a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.<u></u>org</a><br>
<mailto:<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.<u></u>openstack.org</a>><br>
> > ><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>
> ><br>
> > ______________________________<u></u>_________________<br>
> > OpenStack-dev mailing list<br>
> > <a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.<u></u>org</a><br>
<mailto:<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.<u></u>openstack.org</a>><br>
> ><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>
> ><br>
><br>
> ______________________________<u></u>_________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.<u></u>org</a><br>
<mailto:<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.<u></u>openstack.org</a>><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>
><br>
><br>
><br>
> ______________________________<u></u>_________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.<u></u>org</a><br>
<mailto:<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.<u></u>openstack.org</a>><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>
><br>
><br>
><br>
> ______________________________<u></u>_________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.<u></u>org</a><br>
<mailto:<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.<u></u>openstack.org</a>><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>
><br>
<br>
______________________________<u></u>_________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.<u></u>org</a><br>
<mailto:<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.<u></u>openstack.org</a>><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>
<br>
<br>
<br>
<br>
______________________________<u></u>_________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.<u></u>org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>
<br>
</blockquote>
<br>
______________________________<u></u>_________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.<u></u>org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>
</blockquote>
<br>
______________________________<u></u>_________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.<u></u>org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>
</div></div></blockquote></div><br></div></div>