On 12/07/2015 07:49 PM, Adam Young wrote:
On 12/07/2015 06:53 PM, Thomas Goirand wrote:
On 12/01/2015 07:57 AM, Steve Martinelli wrote:
Trying to summarize here...

- There isn't much interest in keeping eventlet around.
- Folks are OK with running keystone in a WSGI server, but feel they are
constrained by Apache.
- uWSGI could help to support multiple web servers.

My opinion:

- Adding support for uWSGI definitely sounds like it's worth
investigating, but not achievable in this release (unless someone
already has something cooked up).
- I'm tempted to let eventlet stick around another release, since it's
causing pain on some of our operators.
- Other folks have managed to run keystone in a web server (and
hopefully not feel pain when doing so!), so it might be worth getting
technical details on just how it was accomplished. If we get an OK from
the operator community later on in mitaka, I'd still be OK with removing
eventlet, but I don't want to break folks.

stevemar

From: John Dewey <j...@dewey.ws>
100% agree.

We should look at uwsgi as the reference architecture. Nginx/Apache/etc
should be interchangeable, and up to the operator which they choose to
use. Hell, with tcp load balancing now in opensource Nginx, I could get
rid of Apache and HAProxy by utilizing uwsgi.

John
The main problem I see with running Keystone (or any other service) in a
web server, is that *I* (as a package maintainer) will loose the control
over when the service is started. Let me explain why that is important
for me.

In Debian, many services/daemons are run, then their API is used by the
package. In the case of Keystone, for example, it is possible to ask,
via Debconf, that Keystone registers itself in the service catalog. If
we get Keystone within Apache, it becomes at least harder to do so.

The other issue is that if all services are sharing the same web server,
restarting the web server restarts all services. Or, said otherwise: if
I need to change a configuration value of any of the services served by
Apache, I will need to restart them all, which is very annoying: I very
much prefer to just restart *ONE* service if I need.

Also, something which we learned the hard way at Mirantis: it is *very*
annoying that Apache restarts every Sunday morning by default in
distributions like Ubuntu and Debian (I'm not sure for the other
distros). No, the default config of logrotate and Apache can't be
changed in distros just to satisfy OpenStack users: there's other users
of Apache in these distros.

Then, yes, uWSGI becomes a nice option. I used it for the Barbican
package, and it worked well. Though the uwsgi package in Debian isn't
very well maintained, and multiple times, Barbican could have been
removed from Debian testing because of RC bugs against uWSGI.

So, all together, I'm a bit reluctant to see the Eventlet based servers
going away. If it's done, then yes, I'll work around it. Though I'd
prefer if it didn't.

You can run one instance of Apache for each service, and have the listen on different ports. Its not how the distros set up apache, but then again, the distros only set up Eventlet with the work we;'ve done.

Eventlet has threading issues I'd rather not debug anymore.



It is also my view that it's up to the deployers to decide how they want
to implement things. For many small use cases, Eventlet performs well
enough.

And for these, Apache is still a better approach, all things considered.

Every way has some pain...we are trying to chose the lesser.


Finally, one thing which I never understood: if Eventlet is bad as an
HTTP server, can't we use anything else written in Python? Isn't it
possible to write a decent HTTP server in Python? Why are we forced into
just Eventlet for doing the job? I haven't searched around, but there
must be loads of alternatives, no?

Crypto. Crypto should not be done in Python. Also, GIL and multi threading make it hard to do in Python. Hence the userland threading approach. Which has an impact on all blocking IO calls.

Kerberos. Other forms of authn/authz - gssapi, federation, mod_lookup_identity, etc. that would need to be implemented in python/eventlet.


There are many ways to get what you want. Each service in their own container is probably the one that maps closest to the type of insulation we'd like to see. Each in their own VM probably makes sense for a non-trivial sized cloud.





Cheers,

Thomas Goirand (zigo)


_______________________________________________
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators


_______________________________________________
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators


_______________________________________________
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Reply via email to