On Thu, Mar 10, 2016 at 10:43 AM, Brant Knudson <b...@acm.org> wrote:
> > > On Thu, Mar 10, 2016 at 8:10 AM, Thomas Herve <the...@redhat.com> wrote: > >> On Thu, Mar 10, 2016 at 2:55 PM, Sean Dague <s...@dague.net> wrote: >> > On 03/10/2016 08:40 AM, Thomas Herve wrote: >> >> On Thu, Mar 10, 2016 at 2:28 PM, Chris Dent <cdent...@anticdent.org> >> wrote: >> >>> +many. It would be great if we just got rid of the runnable web >> >>> servers in the projects and just expose wsgi apps (the tools like >> >>> devstack etc mounted under whatever the available server is). >> >> >> >> Isn't devstack meant for development? Running the APIs in a WSGI >> >> container like Apache or uwsgi makes for a terrible debugging >> >> experience. Just this morning I had to prevent aodh from running in >> >> Apache to be able to run it standalone. >> >> >> >> Also, those apps that use WSGI still bind a different port. The fact >> >> that it runs in Apache doesn't really solve the URLs problem. >> > >> > But they shouldn't. I do realize it's taking a while to get there, but >> > this is the push to get rid of all these weird ports. The point is to >> > get them all on 80 in a subpath or a separate domain. >> > >> > >> > If projects use the pbr wsgi_script directive the wsgi script will run >> > on wsgi ref on the commandline if you need that for debug - >> > >> https://github.com/openstack/keystone/blob/4db54810e58ad86edb92869a608fb5630a6b99e5/setup.cfg#L75 >> > that was built to make this simpler. >> >> Right, but if we move to everything in WSGI besides a subpath, you >> won't be able to switch to the script easily. Unless you actually >> implement that using a reverse proxy. >> >> I totally understand the will to remove those ports from the final >> product. I question whether it's the right choice for devstack. It >> would seem that at least keeping those 'weird' ports for internal >> consumption would be useful. It's not like we're close to use the 65K >> available. >> >> -- >> Thomas >> >> > For some time, devstack has been running with keystone accepting on both > it's legacy ports (:5000 and :35357), and on subpaths (:80/identity and > /identity_admin). I tried to change devstack to have keystone only > listening on subpaths but this is failing in tempest-lib -- see the errors > in https://review.openstack.org/#/c/193894/. At first I thought it would > be best to get tempest-lib doing version discovery but this turned into a > lot of code since version discovery requires quite a bit of parsing and > searching through dicts which always requires lots of error handling and > test code (see reviews ending at https://review.openstack.org/#/c/263452/). > (You might wonder why I didn't use the code that's already in > keystoneclient/keystoneauth for version discovery -- it's because tempest > doesn't use the client libs.) > > Anyways I think the alternative that's going to be backwards compatible is > to have the user be able to pass in the identity endpoints for v2 and v3 > and have tempest use those if provided. I haven't had time to propose this > yet. > > My preference would be to have the keystone processes running separately > under uwsgi or gunicorn, then httpd proxies to that from /identity and > /identity_admin (and :5000 and :35357 for legacy). Hopefully this would be > over a unix socket talking uwsgi protocol or whatever the process and httpd > support. Note that devstack already has a TLS-proxy deployment option > that's similar. I've been hoping to have time to propose the keystone > devstack deployment use this but I'm easily distracted. > > Here's the proposed change to devstack to allow keystone running under uwsgi while apache accepts http / https (using mod_uwsgi_proxy) if you want to take a look: https://review.openstack.org/#/c/291817/ We've got a few too many deployment options for keystone devstack now. I'd like to get this down to just mod_wsgi and mod_uwsgi_proxy. The uwsgi deploy we should be able to get rid of quickly, just add a non-voting job in keystone for mod_uwsgi_proxy and get rid of the uwsgi job. We should be able to get rid of eventlet right away in N since it's not supported to run eventlet keystone anymore. Next, we should be able to simplify the tls-proxy deployment since keystone is always running in apache. Then simplify further: Get rid of the tls-proxy option and instead have keystone apache listen on https + http by default. Then eventually stop listening on http and run https all the time. - 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