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 __________________________________________________________________________ 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
