<HTML>
<HEAD>
<TITLE>Re: [Openstack] Keystone should to Apache HTTPD.</TITLE>
</HEAD>
<BODY>
<FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'>This seems like it could also be done for every other WSGI endpoint right?<BR>
It seems like it should be possible for all WS endpoints to be hosted in apache (or other server) without problems happening.<BR>
This might be connected to extracting/abstractig out eventlet (since a pre-forked apache doesn’t really care about that model) so that it is not always needed.<BR>
<BR>
On 3/1/12 11:05 AM, "Adam Young" <<a href="ayoung@redhat.com">ayoung@redhat.com</a>> wrote:<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'>I wrote up why I think that, at least for Keystone, we should move the<BR>
front end over to Apache HTTPD.<BR>
<BR>
<a href="http://adam.younglogic.com/2012/03/keystone-should-move-to-apache-httpd/">http://adam.younglogic.com/2012/03/keystone-should-move-to-apache-httpd/</a><BR>
<BR>
I've reposted it below.<BR>
<BR>
<BR>
<BR>
Keystone and the other Openstack components run in an <a<BR>
href="<a href="http://www.eventlet.net">Eventlet</a">http://www.eventlet.net">Eventlet</a</a>> based HTTP server. Eventlet<BR>
and <a href="<a href="http://http://pypi.python.org/pypi/greenlet"">http://http://pypi.python.org/pypi/greenlet"</a>> Greenlet</a><BR>
(the project Eventlet is built on) are designed to be highly performant<BR>
in networked environments due to their non-blocking nature. Everything<BR>
is handled in a single thread, and scheduling is performed in user<BR>
space. The one caveat is that not only must the code you write never<BR>
block, the code you call must not block, either. If you are going to<BR>
make a call into a third party library that performs I/O, you need to<BR>
wrap that library in a thread pool.<BR>
<BR>
For Keystone, every call is going to be going through to a Database<BR>
layer, either SQL or LDAP. Which is in turn going to call into the<BR>
native driver for that Database, or the LDAP libraries. Either way, it<BR>
is a native call, and it has to be wrapped in a thread pool.<BR>
<BR>
Keystone is an authentication hub. As such, it is literally the<BR>
"Keystone" of the security architecture around Openstack. In order to do<BR>
anything on any of the other services in Openstack, a use needs a token<BR>
from Keystone. But in order to authenticate against Keystone, the user<BR>
needs to provide a clear-text password. This approach may be sufficient<BR>
to start development, but it is not going to be acceptable when a<BR>
company needs to prove compliance with <a title="Sarbanes Oxley Act of<BR>
2002" href="<a href="http://www.soxlaw.com/">http://www.soxlaw.com/</a>" target="_blank">Sarbanes-Oxley</a>.<BR>
Or <a title="Health Information Privacy"<BR>
href="<a href="http://www.hhs.gov/ocr/privacy/hipaa/understanding/index.html">http://www.hhs.gov/ocr/privacy/hipaa/understanding/index.html</a>"<BR>
target="_blank">HIPPAA</a>. For these cases, we want stronger encryption<BR>
and better authentication management. The Eventlet based web server does<BR>
not currently support forms of authentication other than Basic-Auth.<BR>
Ideally, organizations would be able to employ their Kerberos or Public<BR>
Key Infrastructure (PKI) assets to support their Openstack based<BR>
authentication.<BR>
<BR>
IPv6 is coming. The last block of IPv4 addresses has been allocated. For<BR>
Cloud based deployments, people are going to need large numbers of<BR>
routable IP Addresses. However, Eventlet does not currently support<BR>
IPv6. Work is happening upstream, but it has not yet been commited, and<BR>
will not be available for the Essex release of Openstack.<BR>
<BR>
There is a simple solution. Keystone is a WSGI application, and has<BR>
minimal dependencies on Eventlet. Deploying Keystone in an Apache HTTPD<BR>
server with mod_wsgi running in prefork mode provides the same operating<BR>
environment as Eventlet does. As the de facto standard open source web<BR>
server, it has received a higher degree of scrutiny than most other<BR>
software products. HTTPD support for GSSAPI/Kerberos authentication,<BR>
Client and Server based certificates, and IPv6. It is well supported in<BR>
all the major Linux distributions.<BR>
<BR>
What would the drawbacks be? Probably the first thing people would look<BR>
to from Eventlet is performance. I don't have the hard numbers to<BR>
compare Eventlet to Apache HTTPD, but I do know that Apache is used in<BR>
enough high volume sites that I would not be overly concerned. The<BR>
traffic in an Openstack deployment to a Keystone server is going to be<BR>
about two orders of magnitude less than any other traffic, and is highly<BR>
unlikely to be the bottleneck. Second is the fact that we would be<BR>
pulling in dependencies to Apache HTTPD, and that configuring it would<BR>
be different and more difficult than Eventlet. However, this is a fairly<BR>
well trodden path. The benefits of putting all HTTP traffic behind ports<BR>
80 and 443 overwhelm the drawbacks of configuration.<BR>
<BR>
Since Keystone has just gone through a major reworking, I realize that<BR>
people might be reluctant to support a move like this. However, the<BR>
effect on other components should be minimal or none. Apache HTTPD can<BR>
be set up using the same ports that Keystone already uses, and thus<BR>
replace an existing Keystone install with no changes to the<BR>
configuration or code to the other services. The changes should be<BR>
limited to Keystone alone.<BR>
<BR>
The problem that Eventlet solves does not map to Keystone. The amount of<BR>
work it would take to add the features Keystone really requires to<BR>
Eventlet is significant, is difficult, and is likely to be far buggier<BR>
than using well established and audited libraries. The simpler path<BR>
forward is for Keystone to move over to Apache HTTPD. It is also the<BR>
path for greater stability, security, and growth.<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
_______________________________________________<BR>
Mailing list: <a href="https://launchpad.net/~openstack">https://launchpad.net/~openstack</a><BR>
Post to : <a href="openstack@lists.launchpad.net">openstack@lists.launchpad.net</a><BR>
Unsubscribe : <a href="https://launchpad.net/~openstack">https://launchpad.net/~openstack</a><BR>
More help : <a href="https://help.launchpad.net/ListHelp">https://help.launchpad.net/ListHelp</a><BR>
<BR>
</SPAN></FONT></BLOCKQUOTE>
</BODY>
</HTML>