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...@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.po...@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) >> <daneh...@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-requ...@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-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
