[Openstack-operators] [openstack-dev] [keystone] Removing functionality that was deprecated in Kilo and upcoming deprecated functionality in Mitaka
rmeggins at redhat.com
Tue Dec 8 02:58:32 UTC 2015
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
>>> 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
>>> eventlet, but I don't want to break folks.
>>> From: John Dewey <john at 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.
>> 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
> 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
> 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.
>> Thomas Goirand (zigo)
>> OpenStack-operators mailing list
>> OpenStack-operators at lists.openstack.org
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
More information about the OpenStack-operators