Open Stack

Are we discussing mod_wsgi and Keystone or OpenStack as a general?
If Keystone specific use case, then probably Apache provides broadest
choice of tested external authenticators.
I'm not against uwsgi at all, but to be honest expectation that nginx could
substitute Apache in terms of authentication providers is simply
unrealistic.

A.


On Fri, Sep 25, 2015 at 1:24 PM, Sergii Golovatiuk <sgolovatiuk at mirantis.com
> wrote:

> Alexandr,
>
> oauth, shibboleth & openid support are very keystone specific features.
> Many other openstack projects don't need these modules at all but they may
> require faster HTTP server (lighthttp/nginx).
>
> For all projects we may use "HTTP server -> uwsgi" model and leave apache
> for keystone as " HTTP server -> apache -> uwsgi/mod_wsgi". However, I
> would like to think about whole Openstack ecosystem in general. In that
> case we'll minimize the number of programs operator should have knowledge.
>
>
>
>
> --
> Best regards,
> Sergii Golovatiuk,
> Skype #golserge
> IRC #holser
>
> On Fri, Sep 18, 2015 at 4:28 PM, Alexander Makarov <amakarov at mirantis.com>
> wrote:
>
>> Please consider that we use some apache mods - does
>> nginx/uwsgi/gunicorn have oauth, shibboleth & openid support?
>>
>> On Fri, Sep 18, 2015 at 4:54 PM, Vladimir Kuklin <vkuklin at mirantis.com>
>> wrote:
>> > Folks
>> >
>> > I think we do not need to switch to nginx-only or consider any kind of
>> war
>> > between nginx and apache adherents. Everyone should be able to use
>> > web-server he or she needs without being pinned to the unwanted one. It
>> is
>> > like Postgres vs MySQL war. Why not support both?
>> >
>> > May be someone does not need something that apache supports and nginx
>> not
>> > and needs nginx features which apache does not support. Let's let our
>> users
>> > decide what they want.
>> >
>> > And the first step should be simple here - support for uwsgi. It will
>> allow
>> > for usage of any web-server that can work with uwsgi. It will allow
>> also us
>> > to check for the support of all apache-like bindings like SPNEGO or
>> whatever
>> > and provide our users with enough info on making decisions. I did not
>> > personally test nginx modules for SAML and SPNEGO, but I am pretty
>> confident
>> > about TLS/SSL parts of nginx.
>> >
>> > Moreover, nginx will allow you to do things you cannot do with apache,
>> e.g.
>> > do smart load balancing, which may be crucial for high-loaded
>> installations.
>> >
>> >
>> > On Fri, Sep 18, 2015 at 4:12 PM, Adam Young <ayoung at redhat.com> wrote:
>> >>
>> >> On 09/17/2015 10:04 PM, Jim Rollenhagen wrote:
>> >>
>> >> On Thu, Sep 17, 2015 at 06:48:50PM -0400, Davanum Srinivas wrote:
>> >>
>> >> In the fuel project, we recently ran into a couple of issues with
>> Apache2
>> >> +
>> >> mod_wsgi as we switched Keystone to run . Please see [1] and [2].
>> >>
>> >> Looking deep into Apache2 issues specifically around "apache2ctl
>> graceful"
>> >> and module loading/unloading and the hooks used by mod_wsgi [3]. I
>> started
>> >> wondering if Apache2 + mod_wsgi is the "right" solution and if there
>> was
>> >> something else better that people are already using.
>> >>
>> >> One data point that keeps coming up is, all the CI jobs use Apache2 +
>> >> mod_wsgi so it must be the best solution....Is it? If not, what is?
>> >>
>> >> Disclaimer: it's been a while since I've cared about performance with a
>> >> web server in front of a Python app.
>> >>
>> >> IIRC, mod_wsgi was abandoned for a while, but I think it's being worked
>> >> on again. In general, I seem to remember it being thought of as a bit
>> >> old and crusty, but mostly working.
>> >>
>> >>
>> >> I am not aware of that.  It has been the workhorse of the Python/wsgi
>> >> world for a while, and we use it heavily.
>> >>
>> >> At a previous job, we switched from Apache2 + mod_wsgi to nginx +
>> uwsgi[0]
>> >> and saw a significant performance increase. This was a Django app.
>> uwsgi
>> >> is fairly straightforward to operate and comes loaded with a myriad of
>> >> options[1] to help folks make the most of it. I've played with Ironic
>> >> behind uwsgi and it seemed to work fine, though I haven't done any sort
>> >> of load testing. I'd encourage folks to give it a shot. :)
>> >>
>> >>
>> >> Again, switching web servers is as likely to introduce as to solve
>> >> problems.  If there are performance issues:
>> >>
>> >> 1.  Idenitfy what causes them
>> >> 2.  Change configuration settings to deal with them
>> >> 3.  Fix upstream bugs in the underlying system.
>> >>
>> >>
>> >> Keystone is not about performance.  Keystone is about security.  The
>> cloud
>> >> is designed to scale horizontally first.  Before advocating switching
>> to a
>> >> difference web server, make sure it supports the technologies required.
>> >>
>> >>
>> >> 1. TLS at the latest level
>> >> 2. Kerberos/GSSAPI/SPNEGO
>> >> 3. X509 Client cert validation
>> >> 4. SAML
>> >>
>> >> OpenID connect would be a good one to add to the list;  Its been
>> requested
>> >> for a while.
>> >>
>> >> If Keystone is having performance issues, it is most likely at the
>> >> database layer, not the web server.
>> >>
>> >>
>> >>
>> >> "Programmers waste enormous amounts of time thinking about, or worrying
>> >> about, the speed of noncritical parts of their programs, and these
>> attempts
>> >> at efficiency actually have a strong negative impact when debugging and
>> >> maintenance are considered. We should forget about small efficiencies,
>> say
>> >> about 97% of the time: premature optimization is the root of all evil.
>> Yet
>> >> we should not pass up our opportunities in that critical 3%."
>>  --Donald
>> >> Knuth
>> >>
>> >>
>> >>
>> >> Of course, uwsgi can also be ran behind Apache2, if you'd prefer.
>> >>
>> >> gunicorn[2] is another good option that may be worth investigating; I
>> >> personally don't have any experience with it, but I seem to remember
>> >> hearing it has good eventlet support.
>> >>
>> >> // jim
>> >>
>> >> [0] https://uwsgi-docs.readthedocs.org/en/latest/
>> >> [1] https://uwsgi-docs.readthedocs.org/en/latest/Options.html
>> >> [2] http://gunicorn.org/
>> >>
>> >>
>> __________________________________________________________________________
>> >> 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
>> >>
>> >>
>> >>
>> >>
>> __________________________________________________________________________
>> >> 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
>> >>
>> >
>> >
>> >
>> > --
>> > Yours Faithfully,
>> > Vladimir Kuklin,
>> > Fuel Library Tech Lead,
>> > Mirantis, Inc.
>> > +7 (495) 640-49-04
>> > +7 (926) 702-39-68
>> > Skype kuklinvv
>> > 35bk3, Vorontsovskaya Str.
>> > Moscow, Russia,
>> > www.mirantis.com
>> > www.mirantis.ru
>> > vkuklin at mirantis.com
>> >
>> >
>> __________________________________________________________________________
>> > 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
>> >
>>
>>
>>
>> --
>> Kind Regards,
>> Alexander Makarov,
>> Senior Software Developer,
>>
>> Mirantis, Inc.
>> 35b/3, Vorontsovskaya St., 109147, Moscow, Russia
>>
>> Tel.: +7 (495) 640-49-04
>> Tel.: +7 (926) 204-50-60
>>
>> Skype: MAKAPOB.AJIEKCAHDP
>>
>> __________________________________________________________________________
>> 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
>>
>
>
> __________________________________________________________________________
> 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
>
>


-- 
Adam Heczko
Security Engineer @ Mirantis Inc.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150925/9f65be02/attachment.html>