<html><head><style>body{font-family:Helvetica,Arial;font-size:13px}</style></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;">100% agree.</div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;"><br></div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;">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.</div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;"><br></div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;">John</div><p class="airmail_on">On November 30, 2015 at 1:05:26 PM, Paul Czarkowski (<a href="mailto:pczarkowski+openstackops@bluebox.net">pczarkowski+openstackops@bluebox.net</a>) wrote:</p> <blockquote type="cite" class="clean_bq"><span><div><div></div><div>
<title></title>
<div dir="ltr">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.
<div><br></div>
<div>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.</div>
<div><br></div>
<div>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.</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Mon, Nov 30, 2015 at 2:36 PM, Jesse
Keating <span dir="ltr"><<a href="mailto:jlk@bluebox.net" target="_blank">jlk@bluebox.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">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.
<div><br></div>
<div>I believe we spoke about this at Summit. Have you had time to
look into this scenario and have suggestions?<br>
<div class="gmail_extra"><br clear="all">
<div>
<div>
<div dir="ltr">
<div>
<div dir="ltr">
<div>
<div dir="ltr"><br></div>
<div dir="ltr">- jlk</div>
</div>
</div>
</div>
</div>
</div>
</div>
<br>
<div class="gmail_quote">
<div>
<div class="h5">On Mon, Nov 30, 2015 at 10:26 AM, Steve Martinelli
<span dir="ltr"><<a href="mailto:stevemar@ca.ibm.com" target="_blank">stevemar@ca.ibm.com</a>></span> wrote:<br></div>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>
<div class="h5">
<div>
<p>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: <a href="http://lists.openstack.org/pipermail/openstack-dev/2015-November/080816.html" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/2015-November/080816.html</a><br>
<br>
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).<br>
<br>
removing deprecated functionality<br>
=====================<br>
<br>
This is not a full list, but these are by and large the most
contentious topics.<br>
<br>
* 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.<br>
<br>
* 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.<br>
<br>
* Using LDAP to store project and domain data: The same as above,
see [2] for when we started to issue warnings.<br>
<br>
* for a complete list: <a href="https://blueprints.launchpad.net/keystone/+spec/removed-as-of-mitaka" target="_blank">https://blueprints.launchpad.net/keystone/+spec/removed-as-of-mitaka</a><br>
<br>
functions deprecated as of mitaka<br>
=====================<br>
<br>
The following will adhere to the TC’s new standard on deprecating
functionality [3].<br>
<br>
* 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.<br>
<br>
* 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.<br>
<br>
* 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.<br>
<br>
* for a complete list: <a href="https://blueprints.launchpad.net/keystone/+spec/deprecated-as-of-mitaka" target="_blank">https://blueprints.launchpad.net/keystone/+spec/deprecated-as-of-mitaka</a><br>
<br>
<br>
If you have ANY concern about the following, please speak up now
and let us know!<br>
<br>
<br>
Thanks!<br>
<br>
Steve Martinelli<br>
OpenStack Keystone Project Team Lead<br>
<br>
<br>
[0] <a href="https://github.com/openstack/keystone/blob/b475040636ccc954949e6372a60dd86845644611/keystone/server/eventlet.py#L77-L80" target="_blank">https://github.com/openstack/keystone/blob/b475040636ccc954949e6372a60dd86845644611/keystone/server/eventlet.py#L77-L80</a><br>
[1] <a href="https://github.com/openstack/keystone/blob/28a30f53a6c0d4e84d60795e08f137e8194abbe9/keystone/assignment/backends/ldap.py#L34" target="_blank">https://github.com/openstack/keystone/blob/28a30f53a6c0d4e84d60795e08f137e8194abbe9/keystone/assignment/backends/ldap.py#L34</a><br>
[2] <a href="https://github.com/openstack/keystone/blob/28a30f53a6c0d4e84d60795e08f137e8194abbe9/keystone/resource/backends/ldap.py#L36-L39" target="_blank">https://github.com/openstack/keystone/blob/28a30f53a6c0d4e84d60795e08f137e8194abbe9/keystone/resource/backends/ldap.py#L36-L39</a><br>
[3] <a href="http://governance.openstack.org/reference/tags/assert_follows-standard-deprecation.html" target="_blank">http://governance.openstack.org/reference/tags/assert_follows-standard-deprecation.html</a><br>
<br>
<br></p>
</div>
<br></div>
</div>
_______________________________________________<br>
OpenStack-operators mailing list<br>
<a href="mailto:OpenStack-operators@lists.openstack.org" target="_blank">OpenStack-operators@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators</a><br>
<br></blockquote>
</div>
<br></div>
</div>
</div>
<br>
_______________________________________________<br>
OpenStack-operators mailing list<br>
<a href="mailto:OpenStack-operators@lists.openstack.org">OpenStack-operators@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators</a><br>
<br></blockquote>
</div>
<br></div>
_______________________________________________
<br>OpenStack-operators mailing list
<br>OpenStack-operators@lists.openstack.org
<br>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
<br></div></div></span></blockquote></body></html>