Agree with Vova and Tomasz. It's too late and risky for 6.1, in my opinion.
Best, -jay On 04/29/2015 07:55 AM, Vladimir Kuklin wrote:
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] <mailto:[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] <mailto:[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] <mailto:[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] <mailto:[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 <http://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 <http://www.mirantis.ru/> [email protected] <mailto:[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
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
