Open Stack

Tim,

Thanks for your advice. I respect your point of view and we will definitely encourage our users to try Barbican if they see fits. However, for the sake of Magnum, I think we have to decouple from Barbican at current stage. The coupling of Magnum and Barbican will increase the size of the system by two (1 project -> 2 project), which will significant increase the overall complexities.

·         For developers, it incurs significant overheads on development, quality assurance, and maintenance.

·         For operators, it doubles the amount of efforts of deploying and monitoring the system.

·         For users, a large system is likely to be unstable and fragile which affects the user experience.
In my point of view, I would like to minimize the system we are going to ship, so that we can reduce the overheads of maintenance and provides a stable system to our users.

I noticed that there are several suggestions to “force” our users to install Barbican, which I would respectfully disagree. Magnum is a young project and we are struggling to increase the adoption rate. I think we need to be nice to our users, otherwise, they will choose our competitors (there are container service everywhere). Please understand that we are not a mature project, like Nova, who has thousands of users. We really don’t have the power to force our users to do what they don’t like to do.

I also recognized there are several disagreements from the Barbican team. Per my understanding, most of the complaints are about the re-invention of Barbican equivalent functionality in Magnum. To address that, I am going to propose an idea to achieve the goal without duplicating Barbican. In particular, I suggest to add support for additional authentication system (Keystone in particular) for our Kubernetes bay (potentially for swarm/mesos). As a result, users can specify how to secure their bay’s API endpoint:

·         TLS: This option requires Barbican to be installed for storing the TLS certificates.

·         Keystone: This option doesn’t require Barbican. Users will use their OpenStack credentials to log into Kubernetes.

I am going to send another ML to describe the details. You are welcome to provide your inputs. Thanks.

Best regards,
Hongbin

From: Tim Bell [mailto:Tim.Bell at cern.ch]
Sent: March-19-16 5:55 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [magnum] High Availability


From: Hongbin Lu <hongbin.lu at huawei.com<mailto:hongbin.lu at huawei.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>
Date: Saturday 19 March 2016 at 04:52
To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>
Subject: Re: [openstack-dev] [magnum] High Availability

...
If you disagree, I would request you to justify why this approach works for Heat but not for Magnum. Also, I also wonder if Heat has a plan to set a hard dependency on Barbican for just protecting the hidden parameters.


There is a risk that we use decisions made by other projects to justify how Magnum is implemented. Heat was created 3 years ago according to https://www.openstack.org/software/project-navigator/ and Barbican only 2 years ago, thus Barbican may not have been an option (or a high risk one).

Barbican has demonstrated that the project has corporate diversity and good stability (https://www.openstack.org/software/releases/liberty/components/barbican). There are some areas that could be improved (packaging and puppet modules are often needing some more investment).

I think it is worth a go to try it out and have concrete areas to improve if there are problems.

Tim

If you don’t like code duplication between Magnum and Heat, I would suggest to move the implementation to a oslo library to make it DRY. Thoughts?

[1] https://specs.openstack.org/openstack/heat-specs/specs/juno/encrypt-hidden-parameters.html

Best regards,
Hongbin

From: David Stanek [mailto:dstanek at dstanek.com]
Sent: March-18-16 4:12 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [magnum] High Availability


On Fri, Mar 18, 2016 at 4:03 PM Douglas Mendizábal <douglas.mendizabal at rackspace.com<mailto:douglas.mendizabal at rackspace.com>> wrote:
[snip]
>
> Regarding the Keystone solution, I'd like to hear the Keystone team's feadback on that.  It definitely sounds to me like you're trying to put a square peg in a round hole.
>

I believe that using Keystone for this is a mistake. As mentioned in the blueprint, Keystone is not encrypting the data so magnum would be on the hook to do it. So that means that if security is a requirement you'd have to duplicate more than just code. magnum would start having a larger security burden. Since we have a system designed to securely store data I think that's the best place for data that needs to be secure.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160322/146e7c62/attachment.html>