Open Stack

On 09/22/2015 05:30 PM, Mathieu Gagné wrote:
> On 2015-09-22 4:52 PM, Sean Dague wrote:
>> On 09/22/2015 03:16 PM, Mathieu Gagné wrote:
>>>
>>> The oslo_middleware.ssl middleware looks to offer little overhead and
>>> offer the maximum flexibility. I appreciate the wish to use the Keystone
>>> catalog but I don't feel this is the right answer.
>>>
>>> For example, if I deploy Bifrost without Keystone, I won't have a
>>> catalog to rely on and will still have the same lack of SSL termination
>>> proxy support.
>>>
>>> The simplest solution is often the right one.
>>
>> I do get there are specific edge cases here, but I don't think that in
>> the general case we should be pushing a mode where Keystone is optional.
>> It is a bedrock of our system.
>>
> 
> I understand that Keystone is "a bedrock of our system". This however
> does not make it THE solution when simpler proven existing ones exist. I
> fail to understand why other solutions can't be considered.
> 
> I opened a dialog with the community to express my concerns about the
> lack of universal support for SSL termination proxy so we can find a
> solution together which will cover ALL use cases.
> 
> I proposed using an existing solution (oslo_middleware.ssl) (that I
> didn't know of until now) which takes little to no time to implement and
> cover a lot of use cases and special edge cases.

Does that solution work in the HA Proxy case where there is one
terminating address for multiple backend servers? Because there is the
concern that this impacts not only the Location header, but the link
documents inside the responses which clients are expected to be able to
link.follow. This is an honest question, I don't know how the
oslo_middleware.ssl acts in these cases. And HA Proxy 1 to N mapping is
very common deployment model.

The dialog isn't over, this is still an exploration. Nothing's going to
happen in code right now, because everything is in deep freeze for the
RC spins, the release, and summit planning. But we do need all the cards
on the table about options and trade offs if we are going to get 20+
projects aligned on a thing.

> Operators encounters and *HAVE* to handle a lot of edge cases. We are
> trying *very hard* to open up a dialog with the developer community so
> they can be heard, understood and addressed by sharing our real world
> use cases.
> 
> In that specific case, my impression is that they unfortunately happens
> to not be a priority when evaluating solutions and will actually make my
> job harder. I'm sad to see we can't come with an agreement on that one.
> I feel like I failed to properly communicate my needs as an operator and
> make them understood to others.

Here is the parameter space we are playing with:

1. Are the "Location:" headers correct, or understood in a way that
clients will do the right thing:

a. when direct connected
b. when connected in a 1 to 1 SSL termination proxy
c. when connected in a 1 to N HA Proxy

2. Are the links provided in REST documents correct, or understood in a
way that libraries like requests / phantomjs can follow links natively:

a. when direct connected
b. when connected in a 1 to 1 SSL termination proxy
c. when connected in a 1 to N HA Proxy

3. Are the minority of services that have "operate without keystone" as
a design tenant able to function.

a. when direct connected
b. when connected in a 1 to 1 SSL termination proxy
c. when connected in a 1 to N HA proxy

Today {1,2,3}{a} are handled by services auto figuring out their URL.
That might mean that you jump across from internalURL to publicURL when
following links, because the addresses in the documents are what the
server believes it's URL is.

{1,2,3}{b,c} are handled by manually configuring each api daemon about
what it's URL should be. Recent experiences with a novaclient release
demonstrated that a lot of people aren't actually doing that.

The answer to 3,c seems like it's always going to be manual.

The X-Forwarded-* headers seem like they address {1,3}{b} fine. But the
implications on {1,2,3}{c} are unclear. It's also unclear how {2}{b}
functions in that model and if the clients will interpret that in all
scenarios even document links.

Upgrading the service catalog usage would address {1,2}{a,b,c}, but make
{3}{b} live in the land of manual configs.

We need to get the full map out here, and help fill in details of where
our holes are, which solutions plug which ones, and what set of
tradeoffs we're going to be working around in future releases. Once
we've got that, and our solution going forward, we can start banging the
drum to get all the projects headed in a direction here.

	-Sean

-- 
Sean Dague
http://dague.net