settingsLogin | Registersettings

Re: [openstack-dev] [Openstack-operators] [keystone] Removing functionality that was deprecated in Kilo and upcoming deprecated functionality in Mitaka

0 votes

On 12/01/2015 01: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.

From an interop perspective, this concerns me a bit. My understanding is
that Apache is specifically needed for Federation. Federation is the
norm that we want for environments in the future.

I'd hate to go down a path where the reference architecture we put out
there doesn't support this. It's going to be all the pain of cells /
non-cells that Nova's or nova-net / neutron bifurcation.

Whatever the reference architecture is, it should support Federation. A
non federation capable keystone should be the exception.

  • uWSGI could help to support multiple web servers.

--
Sean Dague
http://dague.net


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
asked Dec 1, 2015 in openstack-dev by Sean_Dague (66,200 points)   4 11 18

15 Responses

0 votes

On Tue, Dec 1, 2015 at 6:05 AM, Sean Dague sean@dague.net wrote:

On 12/01/2015 01: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.

From an interop perspective, this concerns me a bit. My understanding is
that Apache is specifically needed for Federation. Federation is the
norm that we want for environments in the future.

(On a side note from removing eventlet, but related to what Sean said)

A spec has been proposed to make keystone a fully fledged saml2 provider
[0]. Depending on how we feel about implementing and maintaining something
like this, we'd be able to use federation within uWSGI (we would no longer
require Apache for federation). Only bringing this up because it would
also solve the two-reference-architectures problem. A uWSGI reference
architecture could be used for deploying keystone, regardless if you want
federation or not.

We probably wouldn't get a uWSGI reference architecture until after that is
all fleshed out. This is assuming the spec is accepted and implemented in
Mitaka.

Not to take away from the current thread, but it seems partially relevant.
Also, this seems like a good opportunity to gather thoughts on the idea :)

[0] https://review.openstack.org/#/c/244694/5

I'd hate to go down a path where the reference architecture we put out
there doesn't support this. It's going to be all the pain of cells /
non-cells that Nova's or nova-net / neutron bifurcation.

Whatever the reference architecture is, it should support Federation. A
non federation capable keystone should be the exception.

  • uWSGI could help to support multiple web servers.

--
Sean Dague
http://dague.net


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@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@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Dec 1, 2015 by Lance_Bragstad (11,080 points)   2 3 6
0 votes

On Tuesday 01 December 2015 08:50:14 Lance Bragstad wrote:
On Tue, Dec 1, 2015 at 6:05 AM, Sean Dague sean@dague.net wrote:

From an interop perspective, this concerns me a bit. My
understanding is that Apache is specifically needed for
Federation. Federation is the norm that we want for environments
in the future.

(On a side note from removing eventlet, but related to what Sean
said)

A spec has been proposed to make keystone a fully fledged saml2
provider [0]. Depending on how we feel about implementing and
maintaining something like this, we'd be able to use federation
within uWSGI (we would no longer require Apache for federation).
Only bringing this up because it would also solve the
two-reference-architectures problem. A uWSGI reference architecture
could be used for deploying keystone, regardless if you want
federation or not.

We probably wouldn't get a uWSGI reference architecture until after
that is all fleshed out. This is assuming the spec is accepted and
implemented in Mitaka.

[0] https://review.openstack.org/#/c/244694/5

I don't get why we talk about uwsgi in context of federation. uwsgi is
an application server. Apache is a web server. We can still use uwsgi
with apache, there are several modules for that:
https://uwsgi-docs.readthedocs.org/en/latest/Apache.html

Now we require apache for federation and support mod_wsgi (which is
tightly integrated with apache) as an app server. We can still require
Apache and support uwsgi as an app server, without any changes to
federation.

--
Best regards,
Boris Bobrov


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Dec 1, 2015 by Boris_Bobrov (1,720 points)   1 3
0 votes

I just upgraded to keystone liberty for one of my production clouds, and went with apache since eventlet was listed as deprecated. It was pretty easy. Just ran into one issue. RadosGW wouldn't work against it until I added "WSGIChunkedRequest On'" in the config. otherwise, the config as shipped with RDO worked fine. I am running giant radosgw, so future versions may not require that.

Thanks,
Kevin


From: Sean Dague [sean@dague.net]
Sent: Tuesday, December 01, 2015 4:05 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Openstack-operators] [keystone] Removing functionality that was deprecated in Kilo and upcoming deprecated functionality in Mitaka

On 12/01/2015 01: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.

From an interop perspective, this concerns me a bit. My understanding is
that Apache is specifically needed for Federation. Federation is the
norm that we want for environments in the future.

I'd hate to go down a path where the reference architecture we put out
there doesn't support this. It's going to be all the pain of cells /
non-cells that Nova's or nova-net / neutron bifurcation.

Whatever the reference architecture is, it should support Federation. A
non federation capable keystone should be the exception.

  • uWSGI could help to support multiple web servers.

--
Sean Dague
http://dague.net


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@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@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Dec 1, 2015 by Fox,_Kevin_M (29,360 points)   1 3 4
0 votes

On Tue, Dec 1, 2015 at 1:57 AM, Steve Martinelli stevemar@ca.ibm.com
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).

uWSGI is trivial to use, but there are a ton of options that go along with
it. Our current wsgi file that works w/ mod_wsgi pretty much "just works"
for uWSGI. The "configure uWSGI" in a sane way is much much much more in
depth.

  • 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@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

On November 30, 2015 at 1:05:26 PM, Paul Czarkowski (
pczarkowski+openstackops@bluebox.net
pczarkowski+openstackops@bluebox.net) wrote:

I don't have a problem with eventlet itself going away, but I do feel
that keystone should pick a python based web server capable of running WSGI
apps ( such as uWSGI ) for the reference implementation rather than Apache
which can be declared appropriately in the requirements.txt of the project.
I feel it is important to allow the operator to make choices based on their
organization's skill sets ( i.e. apache vs nginx ) to help keep complexity
low.

  I understand there are some newer features that rely on Apache (
  federation, etc ) but we should allow the need for those features inform
  the operators choice of web server rather than force it for everybody.

  Having a default implementation using uWSGI is also more inline
  with the 12 factor way of writing applications and will run a lot more
  comfortably in [application] containers than apache would which is probably
  an important consideration given how many people are focused on being able
  to run openstack projects inside containers.

  On Mon, Nov 30, 2015 at 2:36 PM, Jesse Keating <*jlk@bluebox.net*
  <jlk@bluebox.net>> wrote:
     I have an objection to eventlet going away. We have problems
     with running Apache and mod_wsgi with multiple python virtual environments.
     In some of our stacks we're running both Horizon and Keystone. Each get
     their own virtual environment. Apache mod_wsgi doesn't really work that
     way, so we'd have to do some ugly hacks to expose the python environments
     of both to Apache at the same time.

     I believe we spoke about this at Summit. Have you had time to
     look into this scenario and have suggestions?


     - jlk

     On Mon, Nov 30, 2015 at 10:26 AM, Steve Martinelli <
     *stevemar@ca.ibm.com* <stevemar@ca.ibm.com>> wrote:
     This post is being sent again to the operators mailing list, and
     i apologize if it's duplicated for some folks. The original thread is here:
     *http://lists.openstack.org/pipermail/openstack-dev/2015-November/080816.html*
     


     In the Mitaka release, the keystone team will be removing
     functionality that was marked for deprecation in Kilo, and marking certain
     functions as deprecated in Mitaka (that may be removed in at least 2
     cycles).

     removing deprecated functionality
     =====================

     This is not a full list, but these are by and large the most
     contentious topics.

     * Eventlet support: This was marked as deprecated back in Kilo
     and is currently scheduled to be removed in Mitaka in favor of running
     keystone in a WSGI server. This is currently how we test keystone in the
     gate, and based on the feedback we received at the summit, a lot of folks
     have moved to running keystone under Apache since we’ve announced this
     change. OpenStack's CI is configured to mainly test using this deployment
     model. See [0] for when we started to issue warnings.

     * Using LDAP to store assignment data: Like eventlet support,
     this feature was also deprecated in Kilo and scheduled to be removed in
     Mitaka. To store assignment data (role assignments) we suggest using an SQL
     based backend rather than LDAP. See [1] for when we started to issue
     warnings.

     * Using LDAP to store project and domain data: The same as
     above, see [2] for when we started to issue warnings.

     * for a complete list:
     *https://blueprints.launchpad.net/keystone/+spec/removed-as-of-mitaka*
     <https://blueprints.launchpad.net/keystone/+spec/removed-as-of-mitaka>

     functions deprecated as of mitaka
     =====================

     The following will adhere to the TC’s new standard on
     deprecating functionality [3].

     * LDAP write support for identity: We suggest simply not writing
     to LDAP for users and groups, this effectively makes create, delete and
     update of LDAP users and groups a no-op. It will be removed in the O
     release.

     * PKI tokens: We suggest using UUID or fernet tokens instead.
     The PKI token format has had issues with security and causes problems with
     both horizon and swift when the token contains an excessively large service
     catalog. It will be removed in the O release.

     * v2.0 of our API: Lastly, the keystone team recommends using v3
     of our Identity API. We have had the intention of deprecating v2.0 for a
     while (since Juno actually), and have finally decided to formally deprecate
     v2.0. OpenStack’s CI runs successful v3 only jobs, there is complete
     feature parity with v2.0, and we feel the CLI exposed via openstackclient
     is mature enough to say with certainty that we can deprecate v2.0. It will
     be around for at least FOUR releases, with the authentication routes (POST
     /auth/tokens) potentially sticking around for longer.

     * for a complete list:
     *https://blueprints.launchpad.net/keystone/+spec/deprecated-as-of-mitaka*
     <https://blueprints.launchpad.net/keystone/+spec/deprecated-as-of-mitaka>


     If you have ANY concern about the following, please speak up now
     and let us know!


     Thanks!

     Steve Martinelli
     OpenStack Keystone Project Team Lead


     [0]
     *https://github.com/openstack/keystone/blob/b475040636ccc954949e6372a60dd86845644611/keystone/server/eventlet.py#L77-L80*
     <https://github.com/openstack/keystone/blob/b475040636ccc954949e6372a60dd86845644611/keystone/server/eventlet.py#L77-L80>
     [1]
     *https://github.com/openstack/keystone/blob/28a30f53a6c0d4e84d60795e08f137e8194abbe9/keystone/assignment/backends/ldap.py#L34*
     <https://github.com/openstack/keystone/blob/28a30f53a6c0d4e84d60795e08f137e8194abbe9/keystone/assignment/backends/ldap.py#L34>
     [2]
     *https://github.com/openstack/keystone/blob/28a30f53a6c0d4e84d60795e08f137e8194abbe9/keystone/resource/backends/ldap.py#L36-L39*
     <https://github.com/openstack/keystone/blob/28a30f53a6c0d4e84d60795e08f137e8194abbe9/keystone/resource/backends/ldap.py#L36-L39>
     [3]
     *http://governance.openstack.org/reference/tags/assert_follows-standard-deprecation.html*
     



     _______________________________________________
     OpenStack-operators mailing list

OpenStack-operators@lists.openstack.org
OpenStack-operators@lists.openstack.org
*http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators*

     _______________________________________________
     OpenStack-operators mailing list

OpenStack-operators@lists.openstack.org
OpenStack-operators@lists.openstack.org
*http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators*

  _______________________________________________
  OpenStack-operators mailing list
  OpenStack-operators@lists.openstack.org

  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
  _______________________________________________
  OpenStack-operators mailing list
  OpenStack-operators@lists.openstack.org

  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@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@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Dec 1, 2015 by Morgan_Fainberg (17,320 points)   2 6 9
0 votes

On 12/01/2015 03:50 PM, Fox, Kevin M wrote:
I just upgraded to keystone liberty for one of my production clouds, and went with apache since eventlet was listed as deprecated. It was pretty easy. Just ran into one issue. RadosGW wouldn't work against it until I added "WSGIChunkedRequest On'" in the config. otherwise, the config as shipped with RDO worked fine. I am running giant radosgw, so future versions may not require that.

Thanks for the note. Should this be bug?

Thanks,
Kevin


From: Sean Dague [sean@dague.net]
Sent: Tuesday, December 01, 2015 4:05 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Openstack-operators] [keystone] Removing functionality that was deprecated in Kilo and upcoming deprecated functionality in Mitaka

On 12/01/2015 01: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.
    From an interop perspective, this concerns me a bit. My understanding is
    that Apache is specifically needed for Federation. Federation is the
    norm that we want for environments in the future.

I'd hate to go down a path where the reference architecture we put out
there doesn't support this. It's going to be all the pain of cells /
non-cells that Nova's or nova-net / neutron bifurcation.

Whatever the reference architecture is, it should support Federation. A
non federation capable keystone should be the exception.

  • uWSGI could help to support multiple web servers.

--
Sean Dague
http://dague.net


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@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@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@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Dec 3, 2015 by Adam_Young (19,940 points)   2 7 11
0 votes

Chunked Encoding is a bad idea with modwsgi in general. While enabling it
like that is fine, you are not guaranteed to get 100% consistent results
simply because the wsgi spec did not/does not support it. Not all versions
of mod
wsgi can enable it.

So, in short, officially keystone does not support chunked encoding. If
radosgw cannot work without it, it is a bug against radosgw or something
RDO itself is doing with radosgw.

--morgan
On Dec 2, 2015 23:00, "Adam Young" ayoung@redhat.com wrote:

On 12/01/2015 03:50 PM, Fox, Kevin M wrote:

I just upgraded to keystone liberty for one of my production clouds, and
went with apache since eventlet was listed as deprecated. It was pretty
easy. Just ran into one issue. RadosGW wouldn't work against it until I
added "WSGIChunkedRequest On'" in the config. otherwise, the config as
shipped with RDO worked fine. I am running giant radosgw, so future
versions may not require that.

Thanks for the note. Should this be bug?

Thanks,
Kevin


From: Sean Dague [sean@dague.net]
Sent: Tuesday, December 01, 2015 4:05 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Openstack-operators] [keystone] Removing
functionality that was deprecated in Kilo and upcoming deprecated
functionality in Mitaka

On 12/01/2015 01: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.

From an interop perspective, this concerns me a bit. My understanding is
that Apache is specifically needed for Federation. Federation is the
norm that we want for environments in the future.

I'd hate to go down a path where the reference architecture we put out
there doesn't support this. It's going to be all the pain of cells /
non-cells that Nova's or nova-net / neutron bifurcation.

Whatever the reference architecture is, it should support Federation. A
non federation capable keystone should be the exception.

  • uWSGI could help to support multiple web servers.
    >

--
Sean Dague
http://dague.net


OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
OpenStack-dev-request@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@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@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@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Dec 3, 2015 by Morgan_Fainberg (17,320 points)   2 6 9
0 votes

On 12/03/2015 07:51 AM, Morgan Fainberg wrote:

Chunked Encoding is a bad idea with modwsgi in general. While
enabling it like that is fine, you are not guaranteed to get 100%
consistent results simply because the wsgi spec did not/does not
support it. Not all versions of mod
wsgi can enable it.

So, in short, officially keystone does not support chunked encoding.
If radosgw cannot work without it, it is a bug against radosgw or
something RDO itself is doing with radosgw.

RDO is not doing Keystone in HTTPD by default yet, and I have not come
across the radosgw module at all. Didn't think it was a real issue, but
want to track if it is.

--morgan

On Dec 2, 2015 23:00, "Adam Young" <ayoung@redhat.com
ayoung@redhat.com> wrote:

On 12/01/2015 03:50 PM, Fox, Kevin M wrote:

    I just upgraded to keystone liberty for one of my production
    clouds, and went with apache since eventlet was listed as
    deprecated. It was pretty easy. Just ran into one issue.
    RadosGW wouldn't work against it until I added
    "WSGIChunkedRequest On'" in the config. otherwise, the config
    as shipped with RDO worked fine. I am running giant radosgw,
    so future versions may not require that.


Thanks for the note.  Should this be bug?


    Thanks,
    Kevin
    ________________________________________
    From: Sean Dague [sean@dague.net <mailto:sean@dague.net>]
    Sent: Tuesday, December 01, 2015 4:05 AM
    To: openstack-dev@lists.openstack.org
    <mailto:openstack-dev@lists.openstack.org>
    Subject: Re: [openstack-dev] [Openstack-operators] [keystone]
    Removing functionality that was deprecated in Kilo and
    upcoming deprecated functionality in Mitaka

    On 12/01/2015 01: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.

     From an interop perspective, this concerns me a bit. My
    understanding is
    that Apache is specifically needed for Federation. Federation
    is the
    norm that we want for environments in the future.

    I'd hate to go down a path where the reference architecture we
    put out
    there doesn't support this. It's going to be all the pain of
    cells /
    non-cells that Nova's or nova-net / neutron bifurcation.

    Whatever the reference architecture is, it should support
    Federation. A
    non federation capable keystone should be the exception.

        - uWSGI could help to support multiple web servers.


    --
    Sean Dague
    http://dague.net

    __________________________________________________________________________
    OpenStack Development Mailing List (not for usage questions)
    Unsubscribe:
    OpenStack-dev-request@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@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@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@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@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Dec 3, 2015 by Adam_Young (19,940 points)   2 7 11
0 votes

Not really sure. If its reproducible with hammer+, I'd say yes. giant's keystone support was very basic, and it may not work against Mitaka anyway? It only supports v2.

Thanks,
Kevin


From: Adam Young [ayoung@redhat.com]
Sent: Wednesday, December 02, 2015 8:00 PM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Openstack-operators] [keystone] Removing functionality that was deprecated in Kilo and upcoming deprecated functionality in Mitaka

On 12/01/2015 03:50 PM, Fox, Kevin M wrote:
I just upgraded to keystone liberty for one of my production clouds, and went with apache since eventlet was listed as deprecated. It was pretty easy. Just ran into one issue. RadosGW wouldn't work against it until I added "WSGIChunkedRequest On'" in the config. otherwise, the config as shipped with RDO worked fine. I am running giant radosgw, so future versions may not require that.

Thanks for the note. Should this be bug?

Thanks,
Kevin


From: Sean Dague [sean@dague.net]
Sent: Tuesday, December 01, 2015 4:05 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Openstack-operators] [keystone] Removing functionality that was deprecated in Kilo and upcoming deprecated functionality in Mitaka

On 12/01/2015 01: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.
    From an interop perspective, this concerns me a bit. My understanding is
    that Apache is specifically needed for Federation. Federation is the
    norm that we want for environments in the future.

I'd hate to go down a path where the reference architecture we put out
there doesn't support this. It's going to be all the pain of cells /
non-cells that Nova's or nova-net / neutron bifurcation.

Whatever the reference architecture is, it should support Federation. A
non federation capable keystone should be the exception.

  • uWSGI could help to support multiple web servers.

--
Sean Dague
http://dague.net


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@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@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@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@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Dec 4, 2015 by Fox,_Kevin_M (29,360 points)   1 3 4
0 votes

On Tue, Dec 1, 2015 at 12:57 AM, Steve Martinelli stevemar@ca.ibm.com
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).

What needs to change to support uWSGI? You can already run keystone in
python uwsgi and then front it with nginx:

$ uwsgi --socket 127.0.0.1:5001 --wsgi-file $(which keystone-wsgi-public)
--honour-stdin --enable-threads --workers 6
$ uwsgi --socket 127.0.0.1:35358 --wsgi-file $(which keystone-wsgi-admin)
--honour-stdin --enable-threads --workers 6

$ sudo vi /etc/nginx/sites-available/keystone

server {
listen 5000 defaultserver;
server
name localhost;
location / {
include uwsgiparams;
uwsgi
pass 127.0.0.1:5001;
uwsgiparam SCRIPTNAME /;
}
}
server {
listen 35357 defaultserver;
server
name localhost;
location / {
include uwsgiparams;
uwsgi
pass 127.0.0.1:35358;
uwsgiparam SCRIPTNAME /;
}
}

$ sudo ln -x /etc/nginx/sites-available/keystone /etc/nginx/sites-enabled/

$ sudo nginx

and then you can make your regular curl calls.

Also, you can run keystone with regular http in python uwsgi (uwsgi --http)
and then just do normal reverse proxy (from Apache or nginx or whatever),
which I think would be adequate for keystone.

We don't do anything in keystone to stop deployments in web servers other
than Apache. Keystone is just a regular wsgi app. We document Apache since
it's popular and it provides mod_shib, which is the only saml2 module for
web servers that I know of. Keystone can work with other saml2 modules and
in different servers, it just takes the environment variables that the
module sets and runs it through some mapping code. The mapping code has
been shown to work alternative authentication modules (for ldap and
kerberos).

responded Dec 7, 2015 by Brant_Knudson (5,640 points)   1 2 2
0 votes

On Dec 7, 2015 17:51, "Brant Knudson" blk@acm.org wrote:

On Tue, Dec 1, 2015 at 12:57 AM, Steve Martinelli stevemar@ca.ibm.com
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).

What needs to change to support uWSGI? You can already run keystone in
python uwsgi and then front it with nginx:

$ uwsgi --socket 127.0.0.1:5001 --wsgi-file $(which
keystone-wsgi-public) --honour-stdin --enable-threads --workers 6
$ uwsgi --socket 127.0.0.1:35358 --wsgi-file $(which
keystone-wsgi-admin) --honour-stdin --enable-threads --workers 6

$ sudo vi /etc/nginx/sites-available/keystone

server {
listen 5000 defaultserver;
server
name localhost;
location / {
include uwsgiparams;
uwsgi
pass 127.0.0.1:5001;
uwsgiparam SCRIPTNAME /;
}
}
server {
listen 35357 defaultserver;
server
name localhost;
location / {
include uwsgiparams;
uwsgi
pass 127.0.0.1:35358;
uwsgiparam SCRIPTNAME /;
}
}

$ sudo ln -x /etc/nginx/sites-available/keystone
/etc/nginx/sites-enabled/

$ sudo nginx

and then you can make your regular curl calls.

Also, you can run keystone with regular http in python uwsgi (uwsgi
--http) and then just do normal reverse proxy (from Apache or nginx or
whatever), which I think would be adequate for keystone.

We don't do anything in keystone to stop deployments in web servers other
than Apache. Keystone is just a regular wsgi app. We document Apache since
it's popular and it provides mod_shib, which is the only saml2 module for
web servers that I know of. Keystone can work with other saml2 modules and
in different servers, it just takes the environment variables that the
module sets and runs it through some mapping code. The mapping code has
been shown to work alternative authentication modules (for ldap and
kerberos).

Recently I looked and there seemed to be a similar module for nginx but I
don't know how mature it is. It might be worth exploring with more
discussion on alternatives to apache.

  • Brant


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@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@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Dec 7, 2015 by Morgan_Fainberg (17,320 points)   2 6 9
...