[openstack-dev] [magnum] High Availability
Adrian Otto
adrian.otto at rackspace.com
Thu Mar 17 20:31:33 UTC 2016
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-store
>
> 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
More information about the OpenStack-dev
mailing list