[openstack-dev] [all] Consistent support for SSL termination proxies across all API services

Jim Rollenhagen jim at jimrollenhagen.com
Tue Sep 22 23:00:05 UTC 2015


On Tue, Sep 22, 2015 at 05:30:36PM -0400, 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.
> 
> 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.

FWIW, Ironic fully supports a standalone deployment, and will continue
to do that for the foreseeable future. If it means we need a config that
is inconsistent with the rest of OpenStack, that's what we'll be doing.

// jim



More information about the OpenStack-dev mailing list