<div dir="ltr">Dmitry<div><br></div><div>Although, I am a big fan of disabling replication for RPC, I think it is too late to introduce it so late by default. I would suggest that we control this part of OCF script with a specific parameter 'e.g. enable RPC replication' and set it to 'true' by default. Then we can set this option to false as an experimental feature, run some tests and decide whether it should be enabled by default or not. In this case, users who are interested in this, will be able to enable it when they need it, while we still stick to our old and tested approach.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Dec 2, 2015 at 5:52 PM, Konstantin Kalin <span dir="ltr"><<a href="mailto:kkalin@mirantis.com" target="_blank">kkalin@mirantis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><font face="Menlo">I would add on top of that Dmirty said that HA queues also increases probability to have messages duplications under certain scenarios (besides of that they are ~10x slower). Would Openstack services tolerate if RPC request will be duplicated? What I've already learned - No. Also if <span style="color:rgb(51,51,51);line-height:18px;white-space:nowrap;background-color:rgb(255,255,255)">cluster_partition_handling=autoheal</span> (what we currently have) the messages may be lost as well during the failover scenarios like non-HA queues. Honestly I believe there is no difference between HA queues and non HA-queues in </font><span style="font-family:Menlo">RPC layer </span><span style="font-family:Menlo">fail-tolerance</span><font face="Menlo"> in the way how we use RabbitMQ. </font><div><font face="Menlo"><br></font></div><div><font face="Menlo">Thank you,</font></div><div><font face="Menlo">Konstantin. <br></font><div><div class="h5"><div><br><div><blockquote type="cite"><div>On Dec 2, 2015, at 4:05 AM, Dmitry Mescheryakov <<a href="mailto:dmescheryakov@mirantis.com" target="_blank">dmescheryakov@mirantis.com</a>> wrote:</div><br><div><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">2015-12-02 12:48 GMT+03:00 Sergii Golovatiuk <span dir="ltr"><<a href="mailto:sgolovatiuk@mirantis.com" target="_blank">sgolovatiuk@mirantis.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi,<div class="gmail_extra"><div><div><div dir="ltr"><br></div></div></div>
<br><div class="gmail_quote"><span>On Tue, Dec 1, 2015 at 11:34 PM, Peter Lemenkov <span dir="ltr"><<a href="mailto:lemenkov@gmail.com" target="_blank">lemenkov@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello All!<br>
<br>
Well, side-effects (or any other effects) are quite obvious and<br>
predictable - this will decrease availability of RPC queues a bit.<br>
That's for sure.<br></blockquote><div><br></div></span><div>Imagine the case when user creates VM instance, and some nova messages are lost. I am not sure we want half-created instances. Who is going to clean up them? Since we do not have results of destructive tests, I vote -2 for FFE for this feature.</div></div></div></div></blockquote><div><br></div><div>Sergii, actually messaging layer can not provide any guarantee that it will not happen even if all messages are preserved. Assume the following scenario:</div><div><br></div><div> * nova-scheduler (or conductor?) sends request to nova-compute to spawn a VM</div><div> * nova-compute receives the message and spawned the VM</div><div> * due to some reason (rabbitmq unavailable, nova-compute lagged) nova-compute did not respond within timeout (1 minute, I think)</div><div> * nova-scheduler does not get response within 1 minute and marks the VM with Error status.</div><div><br></div><div>In that scenario no message was lost, but still we have a VM half spawned and it is up to Nova to handle the error and do the cleanup in that case.</div><div><br></div><div>Such issue already happens here and there when something glitches. For instance our favorite MessagingTimeout exception could be caused by such scenario. Specifically, in that example when nova-scheduler times out waiting for reply, it will throw exactly that exception. </div><div><br></div><div>My point is simple - lets increase our architecture scalability by 2-3 times by _maybe_ causing more errors for users during failover. The failover time itself should not get worse (to be tested by me) and errors should be correctly handler by services anyway.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
However, Dmitry's guess is that the overall messaging backplane<br>
stability increase (RabitMQ won't fail too often in some cases) would<br>
compensate for this change. This issue is very much real - speaking of<br>
me I've seen an awful cluster's performance degradation when a failing<br>
RabbitMQ node was killed by some watchdog application (or even worse<br>
wasn't killed at all). One of these issues was quite recently, and I'd<br>
love to see them less frequently.<br>
<br>
That said I'm uncertain about the stability impact of this change, yet<br>
I see a reasoning worth discussing behind it.<br>
<div><div><br>
2015-12-01 20:53 GMT+01:00 Sergii Golovatiuk <<a href="mailto:sgolovatiuk@mirantis.com" target="_blank">sgolovatiuk@mirantis.com</a>>:<br>
> Hi,<br>
><br>
> -1 for FFE for disabling HA for RPC queue as we do not know all side effects<br>
> in HA scenarios.<br>
><br>
> On Tue, Dec 1, 2015 at 7:34 PM, Dmitry Mescheryakov<br>
> <<a href="mailto:dmescheryakov@mirantis.com" target="_blank">dmescheryakov@mirantis.com</a>> wrote:<br>
>><br>
>> Folks,<br>
>><br>
>> I would like to request feature freeze exception for disabling HA for RPC<br>
>> queues in RabbitMQ [1].<br>
>><br>
>> As I already wrote in another thread [2], I've conducted tests which<br>
>> clearly show benefit we will get from that change. The change itself is a<br>
>> very small patch [3]. The only thing which I want to do before proposing to<br>
>> merge this change is to conduct destructive tests against it in order to<br>
>> make sure that we do not have a regression here. That should take just<br>
>> several days, so if there will be no other objections, we will be able to<br>
>> merge the change in a week or two timeframe.<br>
>><br>
>> Thanks,<br>
>><br>
>> Dmitry<br>
>><br>
>> [1] <a href="https://review.openstack.org/247517" rel="noreferrer" target="_blank">https://review.openstack.org/247517</a><br>
>> [2]<br>
>> <a href="http://lists.openstack.org/pipermail/openstack-dev/2015-December/081006.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/2015-December/081006.html</a><br>
>> [3] <a href="https://review.openstack.org/249180" rel="noreferrer" target="_blank">https://review.openstack.org/249180</a><br>
>><br>
>> __________________________________________________________________________<br>
>> OpenStack Development Mailing List (not for usage questions)<br>
>> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org/?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>><br>
><br>
><br>
> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org/?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
<br>
<br>
<br>
</div></div><span><font color="#888888">--<br>
With best regards, Peter Lemenkov.<br>
</font></span><div><div><br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org/?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div></div><br></div></div>
<br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org/?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div></div>
__________________________________________________________________________<br>OpenStack Development Mailing List (not for usage questions)<br>Unsubscribe: <a href="mailto:OpenStack-dev-request@lists.openstack.org" target="_blank">OpenStack-dev-request@lists.openstack.org</a>?subject:unsubscribe<br><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br></div></blockquote></div><br></div></div></div></div></div><br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></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>