<div dir="ltr">Remember that we're talking here about all the projects, not just keystone.  I can't see that we'll move everything to subpaths at any time soon, and until that point we still need to at least make an informal agreement as to which 'default' port to expect services to live on.  Even if that's just for devstack until we get to the subpaths nirvana.<div><br></div><div>It's great that services are looking to the catalog for the locations of endpoints - but unless we're comfortable that every cloud is going to select a bunch of (different) random ports for each service until such time as subpaths are a reality, then we need to communicate in some way.</div><div><br></div><div>I don't see the need for a full web service environment in devstack - all that would really do is limit the choices that ops can make about the best web server/wsgi service.  If people concentrate efforts on apache/mod_wsgi, those wanting to use uwsgi, nginx, gunicorn, etc are going to have a hard road.  There's valid choices for using other web services (in fact, there's some massive arguments against mod_wsgi).</div><div><br></div><div>A simple list is probably enough for a quick ref - it's not a massive blocker if two projects slip up and get the same port number, and yes if they're doing subpaths and not ports then great.  Doesn't need to be a gate item.  But it helps communications if we have a list, even if that's temporary.</div><div><br></div><div>How about a 'default settings' list for a 'standard' reference environment?  When ops deviate from the list (and we will) that's a concious decision we make.  Should we say that the ports used in devstack are the default list, and if a new project wants to get into devstack then they need to choose a port not in use (or subpaths)?</div></div><div class="gmail_extra"><br><div class="gmail_quote">On 11 March 2016 at 05:43, Brant Knudson <span dir="ltr"><<a href="mailto:blk@acm.org" target="_blank">blk@acm.org</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"><br><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="h5">On Thu, Mar 10, 2016 at 8:10 AM, Thomas Herve <span dir="ltr"><<a href="mailto:therve@redhat.com" target="_blank">therve@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span>On Thu, Mar 10, 2016 at 2:55 PM, Sean Dague <<a href="mailto:sean@dague.net" target="_blank">sean@dague.net</a>> wrote:<br>
> On 03/10/2016 08:40 AM, Thomas Herve wrote:<br>
>> On Thu, Mar 10, 2016 at 2:28 PM, Chris Dent <<a href="mailto:cdent%2Bos@anticdent.org" target="_blank">cdent+os@anticdent.org</a>> wrote:<br>
</span><span>>>> +many. It would be great if we just got rid of the runnable web<br>
>>> servers in the projects and just expose wsgi apps (the tools like<br>
>>> devstack etc mounted under whatever the available server is).<br>
>><br>
>> Isn't devstack meant for development? Running the APIs in a WSGI<br>
>> container like Apache or uwsgi makes for a terrible debugging<br>
>> experience. Just this morning I had to prevent aodh from running in<br>
>> Apache to be able to run it standalone.<br>
>><br>
>> Also, those apps that use WSGI still bind a different port. The fact<br>
>> that it runs in Apache doesn't really solve the URLs problem.<br>
><br>
> But they shouldn't. I do realize it's taking a while to get there, but<br>
> this is the push to get rid of all these weird ports. The point is to<br>
> get them all on 80 in a subpath or a separate domain.<br>
><br>
><br>
> If projects use the pbr wsgi_script directive the wsgi script will run<br>
> on wsgi ref on the commandline if you need that for debug -<br>
> <a href="https://github.com/openstack/keystone/blob/4db54810e58ad86edb92869a608fb5630a6b99e5/setup.cfg#L75" rel="noreferrer" target="_blank">https://github.com/openstack/keystone/blob/4db54810e58ad86edb92869a608fb5630a6b99e5/setup.cfg#L75</a><br>
> that was built to make this simpler.<br>
<br>
</span>Right, but if we move to everything in WSGI besides a subpath, you<br>
won't be able to switch to the script easily. Unless you actually<br>
implement that using a reverse proxy.<br>
<br>
I totally understand the will to remove those ports from the final<br>
product. I question whether it's the right choice for devstack. It<br>
would seem that at least keeping those 'weird' ports for internal<br>
consumption would be useful. It's not like we're close to use the 65K<br>
available.<br>
<span><font color="#888888"><br>
--<br>
Thomas<br>
</font></span><div><div><br></div></div></blockquote></div></div><div><br>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 <a href="https://review.openstack.org/#/c/193894/" target="_blank">https://review.openstack.org/#/c/193894/</a>. 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 <a href="https://review.openstack.org/#/c/263452/" target="_blank">https://review.openstack.org/#/c/263452/</a>). (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.)<br><br>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.<br><br>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.<span class="HOEnZb"><font color="#888888"><br><br></font></span></div><span class="HOEnZb"><font color="#888888"><div>- Brant<br><br></div></font></span></div></div></div>
<br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div>