On 09/22/2015 11:34 AM, Ben Nemec wrote: > On 09/22/2015 06:00 AM, Sean Dague wrote: >> On 09/18/2015 02:30 PM, Ben Nemec wrote: >>> I've been dealing with this issue lately myself, so here's my two cents: >>> >>> It seems to me that solving this at the service level is actually kind >>> of wrong. As you've discovered, that requires changes in a bunch of >>> different places to address what is really an external issue. Since >>> it's the terminating proxy that is converting HTTPS traffic to HTTP that >>> feels like the right place for a fix IMHO. >>> >>> My solution has been to have the proxy (HAProxy in my case) rewrite the >>> Location header on redirects (one example for the TripleO puppet config >>> here: https://review.openstack.org/#/c/223330/1/manifests/loadbalancer.pp). >>> >>> I'm not absolutely opposed to having a way to make the services aware of >>> external SSL termination to allow use of a proxy that can't do header >>> rewriting, but I think proxy configuration should be the preferred way >>> to handle it. >> >> 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. >> >> -Sean >> > > That also seems perfectly reasonable, although it looks like we're not > using the service catalog internally now? I see hard-coded endpoints in > nova.conf for the services it talks to.
Nova uses it for cinder, and can for neutron, not for glance. A big part of this is that people kept doing end runs around it instead of thinking about how we make service discovery a base thing that all services use in talking to each other or reflecting back to the user. https://review.openstack.org/#/c/181393/ is an attempt to try to get a handle on the whole situation. -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
