Open Stack

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 <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.
>>>
>>> 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 at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators