Open Stack

On Thu, Mar 10, 2016 at 1:29 PM, Xav Paice <xavpaice at gmail.com> 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 <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.
>>
>> - Brant
>>
>>
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160310/071df441/attachment.html>