I am 100% against the upgrade, folks. We need to ensure that user can use different network for GRE segmentation for high-load cases and mention this in Installation and Operations Guides - there is no time for it.
On Wed, Apr 29, 2015 at 2:33 PM, Tomasz Napierala <[email protected]> wrote: > 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 <[email protected]> > 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 < > [email protected]> 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 <[email protected]> > 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/[email protected]/msg51625.html > > > > -- > > Best regards, > > Bogdan Dobrelya, > > Skype #bogdando_at_yahoo.com > > Irc #bogdando > > > > > > -- > Tomasz 'Zen' Napierala > Product Engineering - Poland > > > > > > > -- Yours Faithfully, Vladimir Kuklin, Fuel Library Tech Lead, Mirantis, Inc. +7 (495) 640-49-04 +7 (926) 702-39-68 Skype kuklinvv 35bk3, Vorontsovskaya Str. Moscow, Russia, www.mirantis.com <http://www.mirantis.ru/> www.mirantis.ru [email protected]
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
