[openstack-dev] [devstack] apache wsgi application support

Adam Young ayoung at redhat.com
Tue Jun 16 19:38:22 UTC 2015

On 06/16/2015 12:25 PM, Sean Dague wrote:
> I was just looking at the patches that put Nova under apache wsgi for
> the API, and there are a few things that I think are going in the wrong
> direction. Largely I think because they were copied from the
> lib/keystone code, which we've learned is kind of the wrong direction.
> The first is the fact that a big reason for putting {SERVICES} under
> apache wsgi is we aren't running on a ton of weird unregistered ports.
> We're running on 80 and 443 (when appropriate). In order to do this we
> really need to namespace the API urls. Which means that service catalog
> needs to be updated appropriately.
> I'd expect nova to be running on http://localhost/compute not

I had writtten this up for just this reason:


Lets make that the cannonical list.

Keystone suffers from the fact that the AUTH_URL is composed lots of 
places, and people hard coded port 5000 in...I would like that to die.
> http://localhost:8774 when running under wsgi. That's going to probably
> interestingly break a lot of weird assumptions by different projects,
> but that's part of the reason for doing this exercise. Things should be
> using the service catalog, and when they aren't, we need to figure it out.
> (Exceptions can be made for third party APIs that don't work this way,
> like the metadata server).
> I also think this -
> https://github.com/openstack-dev/devstack/blob/master/lib/nova#L266-L268
> is completely wrong.
> The Apache configs should instead specify access rules such that the
> installed console entry point of nova-api can be used in place as the
> WSGIScript.
> This should also make lines like -
> https://github.com/openstack-dev/devstack/blob/master/lib/nova#L272 and
> L274 uneeded. (The WSGI Script will be in a known place). It will also
> make upgrades much more friendly.
> I think that we need to get these things sorted before any further
> progression here. Volunteers welcomed to help get us there.
> 	-Sean

More information about the OpenStack-dev mailing list