On 09/22/2015 12:12 PM, Mathieu Gagné wrote: > On 2015-09-22 7:00 AM, Sean Dague wrote: >> >> My feeling on this one is that we've got this thing in OpenStack... the >> Service Catalog. It definitively tells the world what the service >> addresses are. >> >> We should use that in the services themselves to reflect back their >> canonical addresses. Doing point solution rewriting of urls seems odd >> when we could just have Nova/Cinder/etc return documents with URLs that >> match what's in the service catalog for that service. >> > > Sorry, this won't work for us. We have a "split view" in our service > catalog where internal management nodes have a specific catalog and > public nodes (for users) have a different one. > > Implementing the secure_proxy_ssl_header config would require close to > little code change to all projects and accommodate our use case and > other ones we might not think of. For example, how do you know "from" > which of the following URLs (publicURL, internalURL, adminURL) the users > is coming? Each might be different and even not all be SSL. > > The oslo.middleware project already has the SSL middleware [1]. It would > only be a matter of enabling this middleware by default in the paste > config of all projects. > > [1] > https://github.com/openstack/oslo.middleware/blob/master/oslo_middleware/ssl.py
The split view definitely needs to be considered, but a big question here is whether we should really be doing this with multiple urls per catalog entry, or dedicated catalog entries for internal usage. There are a lot of things to work through to get our use of the service catalog consistent and useful going forward. I just don't relish another layer of work arounds that decide the service catalog is not a good way to keep track of what our service urls are, that has to be unwound later. -Sean -- Sean Dague http://dague.net __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev