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/20160319/d47592c5/attachment.html>