Open Stack

On Thu, Mar 10, 2016 at 10:43 AM, Brant Knudson <blk at acm.org> wrote:

>
>
> On Thu, Mar 10, 2016 at 8:10 AM, Thomas Herve <therve at redhat.com> wrote:
>
>> On Thu, Mar 10, 2016 at 2:55 PM, Sean Dague <sean at 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+os at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160311/bad2843c/attachment.html>