On Tue, Dec 1, 2015 at 1:57 AM, Steve Martinelli <steve...@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 <j...@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+openstack...@bluebox.net* > <pczarkowski+openstack...@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 <*j...@bluebox.net* > <j...@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 < > *steve...@ca.ibm.com* <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* > > <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-operat...@lists.openstack.org* > <openstack-operat...@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-operat...@lists.openstack.org* > <openstack-operat...@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-operat...@lists.openstack.org > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators > _______________________________________________ > OpenStack-operators mailing list > openstack-operat...@lists.openstack.org > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators > > > > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
