<br><br>On Monday, December 7, 2015, Thomas Goirand <<a href="mailto:zigo@debian.org">zigo@debian.org</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 12/01/2015 07:57 AM, Steve Martinelli wrote:<br>
> Trying to summarize here...<br>
><br>
> - There isn't much interest in keeping eventlet around.<br>
> - Folks are OK with running keystone in a WSGI server, but feel they are<br>
> constrained by Apache.<br>
> - uWSGI could help to support multiple web servers.<br>
><br>
> My opinion:<br>
><br>
> - Adding support for uWSGI definitely sounds like it's worth<br>
> investigating, but not achievable in this release (unless someone<br>
> already has something cooked up).<br>
> - I'm tempted to let eventlet stick around another release, since it's<br>
> causing pain on some of our operators.<br>
> - Other folks have managed to run keystone in a web server (and<br>
> hopefully not feel pain when doing so!), so it might be worth getting<br>
> technical details on just how it was accomplished. If we get an OK from<br>
> the operator community later on in mitaka, I'd still be OK with removing<br>
> eventlet, but I don't want to break folks.<br>
><br>
> stevemar<br>
><br>
> From: John Dewey <<a href="javascript:;" onclick="_e(event, 'cvml', 'john@dewey.ws')">john@dewey.ws</a>><br>
> 100% agree.<br>
><br>
> We should look at uwsgi as the reference architecture. Nginx/Apache/etc<br>
> should be interchangeable, and up to the operator which they choose to<br>
> use. Hell, with tcp load balancing now in opensource Nginx, I could get<br>
> rid of Apache and HAProxy by utilizing uwsgi.<br>
><br>
> John<br>
<br>
The main problem I see with running Keystone (or any other service) in a<br>
web server, is that *I* (as a package maintainer) will loose the control<br>
over when the service is started. Let me explain why that is important<br>
for me.</blockquote><div><br></div>You can still control *a* web server, it's just that keystone no longer attempts to bundle *the* web server.<br><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
In Debian, many services/daemons are run, then their API is used by the<br>
package. In the case of Keystone, for example, it is possible to ask,<br>
via Debconf, that Keystone registers itself in the service catalog. If<br>
we get Keystone within Apache, it becomes at least harder to do so.</blockquote><div><br></div><div>You start the next paragraph with "the other issue," but I'm not clear on what the issue is here? This sounds like a bunch of complexity that is working as you expect it to.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
The other issue is that if all services are sharing the same web server,<br>
restarting the web server restarts all services. Or, said otherwise: if<br>
I need to change a configuration value of any of the services served by<br>
Apache, I will need to restart them all, which is very annoying: I very<br>
much prefer to just restart *ONE* service if I need.</blockquote><div><br></div><div>As a deployer, I'd solve this by running one API service per server. As a packager, I don't expect you to solve this outside of AIO architectures, in which case, uptime is obviously not a concern.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Also, something which we learned the hard way at Mirantis: it is *very*<br>
annoying that Apache restarts every Sunday morning by default in<br>
distributions like Ubuntu and Debian (I'm not sure for the other<br>
distros). No, the default config of logrotate and Apache can't be<br>
changed in distros just to satisfy OpenStack users: there's other users<br>
of Apache in these distros.</blockquote><div><br></div>Yikes! Is the debian Apache package intended to be useful in production? That doesn't sound like an OpenStack-specific problem at all. How is logrotate involved? Link?<br><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Then, yes, uWSGI becomes a nice option. I used it for the Barbican<br>
package, and it worked well. Though the uwsgi package in Debian isn't<br>
very well maintained, and multiple times, Barbican could have been<br>
removed from Debian testing because of RC bugs against uWSGI.</blockquote><div><br></div><div>uWSGI is a nice option, but no one should be tied to that either-- in the debian world or otherwise.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
So, all together, I'm a bit reluctant to see the Eventlet based servers<br>
going away. If it's done, then yes, I'll work around it. Though I'd<br>
prefer if it didn't.</blockquote><div><br></div><div>Think of it this way: keystone is moving towards using Python where Python excels, and is punting up the stack where Python is handicapped. Don't think of it as a work around, think of it as having the freedom to architect your own deployment.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
It is also my view that it's up to the deployers to decide how they want<br>
to implement things. For many small use cases, Eventlet performs well<br>
enough.</blockquote><div><br></div>Unfortunately, "small" is not "all."<br><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Finally, one thing which I never understood: if Eventlet is bad as an<br>
HTTP server, can't we use anything else written in Python? Isn't it<br>
possible to write a decent HTTP server in Python? Why are we forced into<br>
just Eventlet for doing the job? I haven't searched around, but there<br>
must be loads of alternatives, no?</blockquote><div><br></div><div>Yep! There are many. Eventlet is a bit unique, but ("Core") OpenStack services have historically been tightly bound to Eventlet for it's native-ish threading support. As Keystone has broken free, you are then free to deploy our generic WSGI app/s using any generic WSGI server in any process / threading architecture that suits your requirements.</div><div><br></div><div>We only ever preferred Apache for two reasons:</div><div><br></div><div>1) There was interest in using apache-based auth plugins with keystone.</div><div><br></div><div>2) Everyone sysadmin and their mother knows how to configure Apache.</div><div><br></div><div>It was just well-documented and well-understood.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Cheers,<br>
<br>
Thomas Goirand (zigo)<br>
<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</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>
</blockquote>