... re-adding the operators mailing list. sounds like we should document how to do this, with the assertion that it is not tested with our CI.
with that said, we should try to have a job that sets up keystone with nginx that is run periodically (similar to our eventlet job at the moment). stevemar From: Brant Knudson <b...@acm.org> To: "OpenStack Development Mailing List (not for usage questions)" <openstack-...@lists.openstack.org> Date: 2015/12/07 05:52 PM Subject: Re: [openstack-dev] [Openstack-operators] [keystone] Removing functionality that was deprecated in Kilo and upcoming deprecated functionality in Mitaka On Tue, Dec 1, 2015 at 12: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). What needs to change to support uWSGI? You can already run keystone in python uwsgi and then front it with nginx: $ uwsgi --socket 127.0.0.1:5001 --wsgi-file $(which keystone-wsgi-public) --honour-stdin --enable-threads --workers 6 $ uwsgi --socket 127.0.0.1:35358 --wsgi-file $(which keystone-wsgi-admin) --honour-stdin --enable-threads --workers 6 $ sudo vi /etc/nginx/sites-available/keystone server { listen 5000 default_server; server_name localhost; location / { include uwsgi_params; uwsgi_pass 127.0.0.1:5001; uwsgi_param SCRIPT_NAME /; } } server { listen 35357 default_server; server_name localhost; location / { include uwsgi_params; uwsgi_pass 127.0.0.1:35358; uwsgi_param SCRIPT_NAME /; } } $ sudo ln -x /etc/nginx/sites-available/keystone /etc/nginx/sites-enabled/ $ sudo nginx and then you can make your regular curl calls. Also, you can run keystone with regular http in python uwsgi (uwsgi --http) and then just do normal reverse proxy (from Apache or nginx or whatever), which I think would be adequate for keystone. We don't do anything in keystone to stop deployments in web servers other than Apache. Keystone is just a regular wsgi app. We document Apache since it's popular and it provides mod_shib, which is the only saml2 module for web servers that I know of. Keystone can work with other saml2 modules and in different servers, it just takes the environment variables that the module sets and runs it through some mapping code. The mapping code has been shown to work alternative authentication modules (for ldap and kerberos). - Brant __________________________________________________________________________ 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-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators