Open Stack

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 <sean at dague.net> 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: 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