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 <steve...@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@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