Open Stack

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