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.b...@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...@huawei.com<mailto:hongbin...@huawei.com>> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>> Date: Saturday 19 March 2016 at 04:52 To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org<mailto:openstack-dev@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:dsta...@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.mendiza...@rackspace.com<mailto:douglas.mendiza...@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.
__________________________________________________________________________ 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
