Open Stack

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
> <tnapierala at mirantis.com <mailto: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 <mailto: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 <mailto: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 <mailto: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 <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/>
> vkuklin at mirantis.com <mailto:vkuklin at mirantis.com>
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>