Open Stack

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 <tnapierala at mirantis.com>
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 <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
>
>
>
>
>
>
>


-- 
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
vkuklin at mirantis.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150429/c9f96528/attachment.html>