Open Stack

On Tue, Dec 1, 2015 at 1:57 AM, Steve Martinelli <stevemar at 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 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
>
> On November 30, 2015 at 1:05:26 PM, Paul Czarkowski (
> *pczarkowski+openstackops at bluebox.net*
> <pczarkowski+openstackops at 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 at bluebox.net*
>       <jlk at 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 at ca.ibm.com* <stevemar at 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*
>          <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*
>          <http://governance.openstack.org/reference/tags/assert_follows-standard-deprecation.html>
>
>
>
>          _______________________________________________
>          OpenStack-operators mailing list
> *OpenStack-operators at lists.openstack.org*
>          <OpenStack-operators at lists.openstack.org>
> *http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators*
>          <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators>
>
>
>
>          _______________________________________________
>          OpenStack-operators mailing list
> *OpenStack-operators at lists.openstack.org*
>          <OpenStack-operators at lists.openstack.org>
> *http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators*
>          <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
>       _______________________________________________
>       OpenStack-operators mailing list
>       OpenStack-operators at 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 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/20151201/677e2480/attachment.html>