Open Stack

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20151130/ebfc9d7e/attachment.html>