On 06/16/2015 12:48 PM, Morgan Fainberg wrote:
Long term we want to see Keystone move to http://<host>/identity. However the reason for choosing
5000/35357 for ports was compatibility and avoiding breaking horizon. At the time we did the initial
change over, sharing the root 80/443 ports with horizon was more than "challenging" since
horizon needed to be based at "/".
If that issue/assumption for horizon is no longer present, moving keystone to
be on port 80/443 would be doable. The last factor is that keystone was an a
priori knowledge for discovering other services. As long as we update docs
(possibly 302? For a cycle in devstack from the alternate ports) I think we're
good to make the change.
The change to do this made its way into Horizon (courtesy of Matt Runge)
and is in devstack as well, I think. You need to specify WEBROOT for
the Horizon install.
--Morgan
Sent via mobile
On Jun 16, 2015, at 09:25, Sean Dague <[email protected]> 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
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
--
Sean Dague
http://dague.net
__________________________________________________________________________
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
