<div dir="ltr">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.</div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Apr 29, 2015 at 2:33 PM, Tomasz Napierala <span dir="ltr"><<a href="mailto:tnapierala@mirantis.com" target="_blank">tnapierala@mirantis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I’m -1 for it.<br>
<br>
Considering how much time we needed to troubleshoot the problems already, I don’t think we have time to properly test the upgrade.<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
> On 29 Apr 2015, at 12:37, Sergii Golovatiuk <<a href="mailto:sgolovatiuk@mirantis.com">sgolovatiuk@mirantis.com</a>> wrote:<br>
><br>
> -1 for upgrading it in 6.1. Known devil is better than unknown angel :)<br>
><br>
> In 7.0 we can try 3.5.0 with updated Erlang.<br>
><br>
> ~thanks<br>
><br>
><br>
> --<br>
> Best regards,<br>
> Sergii Golovatiuk,<br>
> Skype #golserge<br>
> IRC #holser<br>
><br>
> On Wed, Apr 29, 2015 at 12:20 PM, Davanum Srinivas <<a href="mailto:dsrinivas@mirantis.com">dsrinivas@mirantis.com</a>> wrote:<br>
> Bogdan,<br>
><br>
> 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].<br>
><br>
> I agree, we should not do this in 6.1, However, we should start testing this ASAP.<br>
><br>
> Another data point, Alexander Nevenchannyy pointed out to me that 3.5.0 came with an updated Erlang that has the following fix:<br>
> OTP-11497  To prevent a race condition if there is a short communication<br>
><br>
> problem when node-down and node-up events are received. They<br>
><br>
> are now stored and later checked if the node came up just<br>
><br>
> before mnesia flagged the node as down. (Thanks to Jonas Falkevik )<br>
><br>
> which seems interesting as well.<br>
><br>
> thanks,<br>
><br>
> dims<br>
><br>
> [0] <a href="https://launchpad.net/ubuntu/vivid/+package/rabbitmq-server" target="_blank">https://launchpad.net/ubuntu/vivid/+package/rabbitmq-server</a><br>
> [1] <a href="http://www.erlang.org/download/otp_src_17.0.readme" target="_blank">http://www.erlang.org/download/otp_src_17.0.readme</a><br>
><br>
> On Wed, Apr 29, 2015 at 4:04 AM, Bogdan Dobrelya <<a href="mailto:bdobrelia@mirantis.com">bdobrelia@mirantis.com</a>> wrote:<br>
> Hello.<br>
><br>
> There are several concerns why we have to upgrade RabbitMQ to 3.4.0 [0]:<br>
> 1) At least two bugfixes related to the current high-load issue with MQ [1]:<br>
> - 26404 prevent queue synchronisation from hanging if there is a very<br>
> short partition just as it starts (since 3.1.0)<br>
> - 26368 prevent autoheal from hanging when loser shuts down before the<br>
> winner  learns it is the winner (since 3.1.0)<br>
> 2) We should as well check how the new 'pause-if-all-down' option works<br>
> for split brain recovery.<br>
> 3) We should address the 'force_boot' recommendations from this mail<br>
> thread [2] to speed up the MQ cluster assemble time.<br>
><br>
> The question is - is it worth it to do this in the 6.1 release scope?<br>
> I vote to postpone this for the 7.0 dev cycle as the impact of such<br>
> changes might be unpredictable.<br>
><br>
> [0] <a href="https://www.rabbitmq.com/release-notes/README-3.4.0.txt" target="_blank">https://www.rabbitmq.com/release-notes/README-3.4.0.txt</a><br>
> [1] <a href="https://bugs.launchpad.net/fuel/+bug/1447619" target="_blank">https://bugs.launchpad.net/fuel/+bug/1447619</a><br>
> [2]<br>
> <a href="http://www.mail-archive.com/openstack-dev@lists.openstack.org/msg51625.html" target="_blank">http://www.mail-archive.com/openstack-dev@lists.openstack.org/msg51625.html</a><br>
><br>
> --<br>
> Best regards,<br>
> Bogdan Dobrelya,<br>
> Skype #<a href="http://bogdando_at_yahoo.com" target="_blank">bogdando_at_yahoo.com</a><br>
> Irc #bogdando<br>
><br>
><br>
<br>
</div></div><span class="HOEnZb"><font color="#888888">--<br>
Tomasz 'Zen' Napierala<br>
Product Engineering - Poland<br>
<br>
<br>
<br>
<br>
<br>
<br>
</font></span></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr">Yours Faithfully,<br>Vladimir Kuklin,<br>Fuel Library Tech Lead,<br>Mirantis, Inc.<br>+7 (495) 640-49-04<br>+7 (926) 702-39-68<br>Skype kuklinvv<br>35bk3, Vorontsovskaya Str.<br>Moscow, Russia,<br><a href="http://www.mirantis.ru/" target="_blank">www.mirantis.com</a><br><a href="http://www.mirantis.ru/" target="_blank">www.mirantis.ru</a><br><a href="mailto:vkuklin@mirantis.com" target="_blank">vkuklin@mirantis.com</a></div></div></div></div>
</div>