I confirmed that ISO 112 with all the modifications to rabbitmq, python-mysqldb, python-sqlalchemy, and MySQL parameters deploys successfully. I did, however, discover that not all services recover the VIP flips. The one in question is the Neutron L3 and DHCP agents die during the unstable phase while Keystone is failing MySQL connections and eventually hits the read_timeout limit of 60s. We need to make these agent launcher scripts a bit more resilient to keystone being temporarily unavailable.
Best Regards, Matthew On Tue, Mar 4, 2014 at 3:54 AM, Vladimir Kuklin <[email protected]> wrote: > Team > > We built an ISO with all the latest code we provided for MySQL and AMQP HA. > This code is not in the stable/4.1 branch now. We are waiting for system > tests results. > Link to the ISO is: > http://srv11-msk.msk.mirantis.net/fuelweb-iso/fuel-gerrit-4.1-111-2014-03-04_01-54-24.iso > > It is passing system tests right now. > > Feel free to test it while I am watching fascinating nightmares as it is 4AM > in Moscow :-) > > > > > On Mon, Mar 3, 2014 at 11:58 PM, Dmitry Borodaenko > <[email protected]> wrote: >> >> In that case we shouldn't change Murano manifests for this bug, and >> when Murano migrates to oslo.messaging, we should take sure it uses >> the same amqp_hosts Puppet variable as other OS services. >> >> Thanks, >> -DmitryB >> >> On Mon, Mar 3, 2014 at 5:20 AM, Serg Melikyan <[email protected]> >> wrote: >> >>Murano seems to be using its own implementation of RabbitMQ based RPC >> >> backend instead of an almost homogenous zoo of impl_kombu >> >> implementations >> >> used by the rest of OpenStack. >> > >> > Yes, currently Murano uses own messaging library implementation based on >> > Puka AMQP library. We are moving to oslo.messaging and in the next >> > version >> > of Murano, part of communication will be going through oslo.messaging. >> > >> > To configure access credentials to RabbitMQ in Murano v0.4.1 use our >> > sample >> > config files as a reference: >> > >> > murano-api >> > murano-conductor >> > >> >> I'm not even sure it has the same reconnect mechanism as impl_kombu, >> >> can >> >> anyone from Murano team comment? >> > >> > No, I believe we use different reconnect logic in Murano. We use >> > reconnect >> > with increasing delay between consecutive failed connection attempts: >> > example. There are no configurable options related to reconnects. >> > >> > -- >> > Serg Melikyan, Senior Software Engineer at Mirantis, Inc. >> > http://mirantis.com | [email protected] >> > >> > +7 (495) 640-4904, 0261 >> > +7 (903) 156-0836 >> > >> > -- >> > Mailing list: https://launchpad.net/~fuel-dev >> > Post to : [email protected] >> > Unsubscribe : https://launchpad.net/~fuel-dev >> > More help : https://help.launchpad.net/ListHelp >> > >> >> >> >> -- >> Dmitry Borodaenko >> >> -- >> Mailing list: https://launchpad.net/~fuel-dev >> Post to : [email protected] >> Unsubscribe : https://launchpad.net/~fuel-dev >> More help : https://help.launchpad.net/ListHelp > > > > > -- > Yours Faithfully, > Vladimir Kuklin, > Senior Deployment Engineer, > Mirantis, Inc. > +7 (495) 640-49-04 > +7 (926) 702-39-68 > Skype kuklinvv > 45bk3, Vorontsovskaya Str. > Moscow, Russia, > www.mirantis.com > www.mirantis.ru > [email protected] > > -- > Mailing list: https://launchpad.net/~fuel-dev > Post to : [email protected] > Unsubscribe : https://launchpad.net/~fuel-dev > More help : https://help.launchpad.net/ListHelp > -- Mailing list: https://launchpad.net/~fuel-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~fuel-dev More help : https://help.launchpad.net/ListHelp
