[openstack-dev] [Fuel] Rabbitmq 3.4.0 upgrade for the 6.1 release, is it worth it?

Tomasz Napierala tnapierala at mirantis.com
Wed Apr 29 11:33:37 UTC 2015


I’m -1 for it.

Considering how much time we needed to troubleshoot the problems already, I don’t think we have time to properly test the upgrade.


> On 29 Apr 2015, at 12:37, Sergii Golovatiuk <sgolovatiuk at mirantis.com> wrote:
> 
> -1 for upgrading it in 6.1. Known devil is better than unknown angel :)
> 
> In 7.0 we can try 3.5.0 with updated Erlang.
> 
> ~thanks
> 
> 
> --
> Best regards,
> Sergii Golovatiuk,
> Skype #golserge
> IRC #holser
> 
> On Wed, Apr 29, 2015 at 12:20 PM, Davanum Srinivas <dsrinivas at mirantis.com> wrote:
> Bogdan,
> 
> Pacemaker, corosync etc, we picked vivid packages right? So don't we test what's in vivid for this too? Apparently it's 3.4.3-2 per [0].
> 
> I agree, we should not do this in 6.1, However, we should start testing this ASAP.
> 
> Another data point, Alexander Nevenchannyy pointed out to me that 3.5.0 came with an updated Erlang that has the following fix:
> OTP-11497  To prevent a race condition if there is a short communication
> 
> problem when node-down and node-up events are received. They
> 
> are now stored and later checked if the node came up just
> 
> before mnesia flagged the node as down. (Thanks to Jonas Falkevik )
> 
> which seems interesting as well.
> 
> thanks,
> 
> dims
> 
> [0] https://launchpad.net/ubuntu/vivid/+package/rabbitmq-server
> [1] http://www.erlang.org/download/otp_src_17.0.readme
> 
> On Wed, Apr 29, 2015 at 4:04 AM, Bogdan Dobrelya <bdobrelia at mirantis.com> wrote:
> Hello.
> 
> There are several concerns why we have to upgrade RabbitMQ to 3.4.0 [0]:
> 1) At least two bugfixes related to the current high-load issue with MQ [1]:
> - 26404 prevent queue synchronisation from hanging if there is a very
> short partition just as it starts (since 3.1.0)
> - 26368 prevent autoheal from hanging when loser shuts down before the
> winner  learns it is the winner (since 3.1.0)
> 2) We should as well check how the new 'pause-if-all-down' option works
> for split brain recovery.
> 3) We should address the 'force_boot' recommendations from this mail
> thread [2] to speed up the MQ cluster assemble time.
> 
> The question is - is it worth it to do this in the 6.1 release scope?
> I vote to postpone this for the 7.0 dev cycle as the impact of such
> changes might be unpredictable.
> 
> [0] https://www.rabbitmq.com/release-notes/README-3.4.0.txt
> [1] https://bugs.launchpad.net/fuel/+bug/1447619
> [2]
> http://www.mail-archive.com/openstack-dev@lists.openstack.org/msg51625.html
> 
> --
> Best regards,
> Bogdan Dobrelya,
> Skype #bogdando_at_yahoo.com
> Irc #bogdando
> 
> 

-- 
Tomasz 'Zen' Napierala
Product Engineering - Poland









More information about the OpenStack-dev mailing list