Open Stack

On 03/23/2016 04:45 PM, Ian Cordasco wrote:
> -----Original Message-----
> From: Monty Taylor <mordred at inaugust.com>
> Reply: OpenStack Development Mailing List (not for usage questions) <openstack-dev at lists.openstack.org>
> Date: March 22, 2016 at 18:49:41
> To: openstack-dev at lists.openstack.org <openstack-dev at lists.openstack.org>
> Subject:  Re: [openstack-dev] [magnum] Streamline adoption of Magnum
>
>> On 03/22/2016 06:27 PM, Kevin Carter wrote:
>>> /me wearing my deployer hat now: Many of my customers and product folks
>>> want Magnum but they also want magnum to be as secure and stable as
>>> possible. If Barbican is the best long term solution for the project it
>>> would make sense to me that Magnum remain on course with Barbican as the
>>> defacto way of deploying in production. IMHO building alternative means
>>> for certificate management is a distraction and will only confuse folks
>>> looking to deploy Magnum into production.
>>
>> I'm going to agree. This reminds me of people who didn't want to run
>> keystone back in the day. Those people were a distraction, and placating
>> them hampered OpenStack's progress by probably several years.
>
> Right. Barbican is a good service that is actually necessary for a cloud (see also other similar services announced by the likes of Hashicorp). Magnum relying on it to securely store information makes perfect sense.
>
>>>> Some ops teams are willing to
>>>> adopt a new service, but not two. They only want to add Magnum and not
>>>> Barbican.
>>>
>>> It would seem to me that once the Barbican dependency is well
>>> documented, which it should be at this point, Barbican is be easy to
>>> accept especially with the understanding of why it is needed. Many of
>>> the deployment projects are creating the automation needed to make the
>>> adoption of services simpler and I'd imagine deployment automation is
>>> the largest hurdle to wide spread adoption for both Barbican and Magnum.
>>> If the OPS team you mention does not want both services it would seem
>>> they can use "local file" option; this is similar to Cinder+LVM and
>>> Glance+file_store both of which have scale operational issues in production.
>>
>> Agree.
>
> If it wasn't obvious, I also agree. That said, people will still try to use these to avoid the illusion of additional costs. They tend to ignore the cost of the repercussions of these decisions down the road.
>
>>>> We think that once those operators become familiar with
>>>> Magnum, adding Barbican will follow. In the mean time, we’d like to
>>>> offer a Barbican alternative that allows Magnum to scale beyond one
>>>> conductor, and allows for encrypted storage of TLC credentials needed
>>>> for unattended bay operations.
>>>
>>> If all of this is to simplify or provide for the developer/"someone
>>> kicking the tires" use case I'd imagine the "local file" storage would
>>> be sufficient. If the acceptance of Barbican is too much to handle or
>>> introduce into an active deployment (I'm not sure why that would be
>>> especially if they're adding Magnum), the synchronization of locally
>>> stored certificates across multiple hosts is manageable and can be
>>> handled by a very long list of other pre-existing operational means.
>
> Right, they may be using any of the other recently announced services created and provided by other groups.
>
>>>> A blueprint [2] was recently proposed to
>>>> address this. We discussed this in our team meeting today [3], where we
>>>> used an etherpad [4] to collaborate on options that could be used as
>>>> alternatives besides the ones offered today. This thread is not intended
>>>> to answer how to make Barbican easier to adopt, but rather how to make
>>>> Magnum easier to adopt while keeping Barbican as the default
>>>> best-practice choice for certificate storage.
>>>
>>> I'd like there _NOT_ to be an "easy button" way for operators to hang
>>> themselves in production by following a set of "quick start
>>> instructions" under the guise of "easy to adopt". If Barbican is the
>>> best-practice lets keep it that way. If for some reason Barbican is hard
>>> to adopt lets identify those difficulties and get them fixed. Going down
>>> the path of NIH or alternative less secure solutions because someone
>>> (not identified here or speaking for themselves) has said they don't
>>> want Barbican or deploying it is hard seems like a recipe for
>>> fragmentation and disaster.
>>
>> Agree.
>
> Perhaps, if the problem is less that two new services is problematic and the real problem is one (or some combination) of:
>
> - Magnum and Barbican's dependency is poorly (if at all) documented
> - Magnum and Barbican don't have documentation to deploy the services
> - Magnum should support a variety of services like Barbican (e.g., adding support for Vault)
>
> There are things that can be done. One thing is writing documentation. Another would be a driver for Vault or any other service the community might want. (Which is not to imply that there is a desire to rely on those, just that those are services that might be easier for our hypothetical operators to deploy.)

Yah. I'm not crazy about OpenStack services spending much time worrying 
about integration with other non-OpenStack services when there is also a 
clear OpenStack service ... however, I'd rather see a Vault driver in 
Magnum as a vehicle to pain avoidance and not an in-tree barbican-lite.

I'd still rather just declare the dependency and be done with it.

Monty