[openstack-dev] [magnum] High Availability

Hongbin Lu hongbin.lu at huawei.com
Thu Mar 17 21:25:42 UTC 2016


Adrian,

I think we need a boarder set of inputs in this matter, so I moved the discussion from whiteboard back to here. Please check my replies inline.

> I would like to get a clear problem statement written for this.
> As I see it, the problem is that there is no safe place to put certificates in clouds that do not run Barbican.
> It seems the solution is to make it easy to add Barbican such that it's included in the setup for Magnum.
No, the solution is to explore an non-Barbican solution to store certificates securely.

> Magnum should not be in the business of credential storage when there is an existing service focused on that need.
>
> Is there an issue with running Barbican on older clouds?
> Anyone can choose to use the builtin option with Magnum if hey don't have Barbican.
> A known limitation of that approach is that certificates are not replicated.
I guess the *builtin* option you referred is simply placing the certificates to local file system. A few of us had concerns on this approach (In particular, Tom Cammann has gave -2 on the review [1]) because it cannot scale beyond a single conductor. Finally, we made a compromise to land this option and use it for testing/debugging only. In other words, this option is not for production. As a result, Barbican becomes the only option for production which is the root of the problem. It basically forces everyone to install Barbican in order to use Magnum.

[1] https://review.openstack.org/#/c/212395/ 

> It's probably a bad idea to replicate them.
> That's what Barbican is for. --adrian_otto
Frankly, I am surprised that you disagreed here. Back to July 2015, we all agreed to have two phases of implementation and the statement was made by you [2].

================================================================
#agreed Magnum will use Barbican for an initial implementation for certificate generation and secure storage/retrieval.  We will commit to a second phase of development to eliminating the hard requirement on Barbican with an alternate implementation that implements the functional equivalent implemented in Magnum, which may depend on libraries, but not Barbican.
================================================================

[2] http://lists.openstack.org/pipermail/openstack-dev/2015-July/069130.html

Best regards,
Hongbin

-----Original Message-----
From: Adrian Otto [mailto:adrian.otto at rackspace.com] 
Sent: March-17-16 4:32 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [magnum] High Availability

I have trouble understanding that blueprint. I will put some remarks on the whiteboard. Duplicating Barbican sounds like a mistake to me.

--
Adrian

> On Mar 17, 2016, at 12:01 PM, Hongbin Lu <hongbin.lu at huawei.com> wrote:
> 
> The problem of missing Barbican alternative implementation has been raised several times by different people. IMO, this is a very serious issue that will hurt Magnum adoption. I created a blueprint for that [1] and set the PTL as approver. It will be picked up by a contributor once it is approved.
> 
> [1] 
> https://blueprints.launchpad.net/magnum/+spec/barbican-alternative-sto
> re
> 
> Best regards,
> Hongbin
> 
> -----Original Message-----
> From: Ricardo Rocha [mailto:rocha.porto at gmail.com]
> Sent: March-17-16 2:39 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [magnum] High Availability
> 
> Hi.
> 
> We're on the way, the API is using haproxy load balancing in the same way all openstack services do here - this part seems to work fine.
> 
> For the conductor we're stopped due to bay certificates - we don't currently have barbican so local was the only option. To get them accessible on all nodes we're considering two options:
> - store bay certs in a shared filesystem, meaning a new set of 
> credentials in the boxes (and a process to renew fs tokens)
> - deploy barbican (some bits of puppet missing we're sorting out)
> 
> More news next week.
> 
> Cheers,
> Ricardo
> 
>> On Thu, Mar 17, 2016 at 6:46 PM, Daneyon Hansen (danehans) <danehans at cisco.com> wrote:
>> All,
>> 
>> Does anyone have experience deploying Magnum in a highly-available fashion?
>> If so, I'm interested in learning from your experience. My biggest 
>> unknown is the Conductor service. Any insight you can provide is 
>> greatly appreciated.
>> 
>> Regards,
>> Daneyon Hansen
>> 
>> _____________________________________________________________________
>> _ ____ OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: 
>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> ______________________________________________________________________
> ____ OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: 
> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> ______________________________________________________________________
> ____ OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: 
> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



More information about the OpenStack-dev mailing list