fuel-dev team mailing list archive

[Matthew Mosesohn <mmosesohn@xxxxxxxxxxxx>]

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 <vkuklin@xxxxxxxxxxxx> 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
> <dborodaenko@xxxxxxxxxxxx> 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 <smelikyan@xxxxxxxxxxxx>
>> 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 | smelikyan@xxxxxxxxxxxx
>> >
>> > +7 (495) 640-4904, 0261
>> > +7 (903) 156-0836
>> >
>> > --
>> > Mailing list: https://launchpad.net/~fuel-dev
>> > Post to     : fuel-dev@xxxxxxxxxxxxxxxxxxx
>> > Unsubscribe : https://launchpad.net/~fuel-dev
>> > More help   : https://help.launchpad.net/ListHelp
>> >
>>
>>
>>
>> --
>> Dmitry Borodaenko
>>
>> --
>> Mailing list: https://launchpad.net/~fuel-dev
>> Post to     : fuel-dev@xxxxxxxxxxxxxxxxxxx
>> 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
> vkuklin@xxxxxxxxxxxx
>
> --
> Mailing list: https://launchpad.net/~fuel-dev
> Post to     : fuel-dev@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~fuel-dev
> More help   : https://help.launchpad.net/ListHelp
>