Open Stack

-----Original Message-----
From: Hongbin Lu <hongbin.lu at huawei.com>
Reply: OpenStack Development Mailing List (not for usage questions) <openstack-dev at lists.openstack.org>
Date: March 17, 2016 at 20:48:59
To: OpenStack Development Mailing List (not for usage questions) <openstack-dev at lists.openstack.org>
Subject:  Re: [openstack-dev] [magnum] High Availability

> Thanks Adrian,
>  
> I think the Keystone approach will work. For others, please speak up if it doesn’t work  
> for you.

So I think we need to clear out some assumptions before declaring that it will work.

First, we have the assumption that people not wanting to deploy Magnum with Barbican are using an older OpenStack version on the whole. Let's assume that's true. You're now choosing to depend on a Keystone v3 feature that should have been supported in Grizzly. This assumes a few things:

- Operators already had v3 turned on in Grizzly (which is *highly* unlikely)
- The API feature didn't have show stopping bugs back then

Will Magnum now start rigorously testing the integration between this feature and magnum at the gate dating all the way back to Grizzly so these (supposed) operators (none of whom have stepped forth in this discussion and apparently do not include Ricardo) can be certain their data won't be lost?

Further, how will this affect any future acceptance into the vulnerability-managed tag? Magnum would need a full security audit and I'm certain this particular feature will set off several red flags. And given that few contributors to magnum seem to have the expertise with this kind of work, I have little confidence in anyone relying on this in production. It will likely be far less secure or trustworthy than deploying Barbican.

I'd also like to challenge the idea of doing something unless it doesn't work for someone. That shouldn't be the barrier for acceptance in an OpenStack project and especially not in Magnum. You're introducing several points of failure for security. You're potentially harming the future of Magnum (by excluding it from the VMT until this code is fixed/removed). You're solving for a demographic that doesn't seem to be represented here.

This feature needs far more justification in the way of *real* user stories for magnum where they cannot or will not deploy Barbican.

--  
Ian Cordasco