Open Stack

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150925/442c0001/attachment.html>