Open Stack

On Monday, December 7, 2015, Thomas Goirand <zigo at debian.org> 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 <john at dewey.ws <javascript:;>>
> > 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.


You can still control *a* web server, it's just that keystone no
longer attempts to bundle *the* web server.


>
> 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.


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.


>
> 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.


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.


>
> 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.


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?


>
> 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.


uWSGI is a nice option, but no one should be tied to that either-- in the
debian world or otherwise.


>
> 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.


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.


>
> 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.


Unfortunately, "small" is not "all."


>
> 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?


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.

We only ever preferred Apache for two reasons:

1) There was interest in using apache-based auth plugins with keystone.

2) Everyone sysadmin and their mother knows how to configure Apache.

It was just well-documented and well-understood.


>
> Cheers,
>
> Thomas Goirand (zigo)
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151207/0507af8f/attachment.html>