Open Stack

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


On November 30, 2015 at 1:05:26 PM, Paul Czarkowski (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>
      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> 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


         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



         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

         [1]
         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

         [3]
         http://governance.openstack.org/reference/tags/assert_follows-standard-deprecation.html




         _______________________________________________
         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-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



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20151201/d6506f88/attachment.html>