On Thu, Mar 10, 2016 at 1:29 PM, Xav Paice <[email protected]> wrote:
> 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. > > 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. > > 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). > > 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. > > I really disagree that it doesn't need to be a gate item. It should absolutely be gated on that services can run as a subpath. > 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)? > > On 11 March 2016 at 05:43, Brant Knudson <[email protected]> wrote: > >> >> >> On Thu, Mar 10, 2016 at 8:10 AM, Thomas Herve <[email protected]> wrote: >> >>> On Thu, Mar 10, 2016 at 2:55 PM, Sean Dague <[email protected]> wrote: >>> > On 03/10/2016 08:40 AM, Thomas Herve wrote: >>> >> On Thu, Mar 10, 2016 at 2:28 PM, Chris Dent <[email protected]> >>> 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. >> >> - Brant >> >> >> __________________________________________________________________________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: >> [email protected]?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
