<div dir="ltr">Hi, Andrew<div><br></div><div>><span style="font-size:12.6666669845581px">Ah good, I understood it correctly then :)</span></div><span style="font-size:12.6666669845581px">> I would be interested in your opinion of how the other agent does the bootstrapping (ie. without notifications or master/slave).</span><br style="font-size:12.6666669845581px"><div>><span style="font-size:12.6666669845581px">That makes sense, the part I’m struggling with is that it sounds like the other agent shouldn’t work at all.</span></div><span style="font-size:12.6666669845581px">> Yet we’ve used it extensively and not experienced these kinds of hangs.</span><div>Regarding other scripts - I am not aware of any other scripts that actually handle cloned rabbitmq server. I may be mistaking, of course. So if you are aware if these scripts succeed in creating rabbitmq cluster which actually survives 1-node or all-node failure scenarios and reassembles the cluster automatically - please, let us know.</div><div><br></div><div>> <span style="font-size:12.6666669845581px">Changing the state isn’t ideal but there is precedent, the part that has me concerned is the error codes coming out of notify.</span></div><span style="font-size:12.6666669845581px">> Apart from producing some log messages, I can’t think how it would produce any recovery.</span><br style="font-size:12.6666669845581px"><br style="font-size:12.6666669845581px"><span style="font-size:12.6666669845581px">> Unless you’re relying on the subsequent monitor operation to notice the error state.</span><br style="font-size:12.6666669845581px"><span style="font-size:12.6666669845581px">> I guess that would work but you might be waiting a while for it to notice.</span><div><br></div><div>Yes, we are relying on subsequent monitor operations. We also have several OCF check levels to catch a case when one node does not have rabbitmq application started properly (btw, there was a strange bug that we had to wait for several non-zero checks to fail to get the resource to restart <a href="http://bugs.clusterlabs.org/show_bug.cgi?id=5243">http://bugs.clusterlabs.org/show_bug.cgi?id=5243</a>) . I now remember, why we did notify errors - for error logging, I guess.</div><div> </div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Nov 12, 2015 at 1:30 AM, Andrew Beekhof <span dir="ltr"><<a href="mailto:abeekhof@redhat.com" target="_blank">abeekhof@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
> On 11 Nov 2015, at 11:35 PM, Vladimir Kuklin <<a href="mailto:vkuklin@mirantis.com">vkuklin@mirantis.com</a>> wrote:<br>
><br>
> Hi, Andrew<br>
><br>
> Let me answer your questions.<br>
><br>
> This agent is active/active which actually marks one of the node as 'pseudo'-master which is used as a target for other nodes to join to. We also check which node is a master and use it in monitor action to check whether this node is clustered with this 'master' node. When we do cluster bootstrap, we need to decide which node to mark as a master node. Then, when it starts (actually, promotes), we can finally pick its name through notification mechanism and ask other nodes to join this cluster.<br>
<br>
</span>Ah good, I understood it correctly then :)<br>
I would be interested in your opinion of how the other agent does the bootstrapping (ie. without notifications or master/slave).<br>
<span class=""><br>
><br>
> Regarding disconnect_node+forget_cluster_node this is quite simple - we need to eject node from the cluster. Otherwise it is mentioned in the list of cluster nodes and a lot of cluster actions, e.g. list_queues, will hang forever as well as forget_cluster_node action.<br>
<br>
</span>That makes sense, the part I’m struggling with is that it sounds like the other agent shouldn’t work at all.<br>
Yet we’ve used it extensively and not experienced these kinds of hangs.<br>
<span class=""><br>
><br>
> We also handle this case whenever a node leaves the cluster. If you remember, I wrote an email to Pacemaker ML regarding getting notifications on node unjoin event '[openstack-dev] [Fuel][Pacemaker][HA] Notifying clones of offline nodes’.<br>
<br>
</span>Oh, I recall that now.<br>
<span class=""><br>
> So we went another way and added a dbus daemon listener that does the same when node lefts corosync cluster (we know that this is a little bit racy, but disconnect+forget actions pair is idempotent).<br>
><br>
> Regarding notification commands - we changed behaviour to the one that fitter our use cases better and passed our destructive tests. It could be Pacemaker-version dependent, so I agree we should consider changing this behaviour. But so far it worked for us.<br>
<br>
</span>Changing the state isn’t ideal but there is precedent, the part that has me concerned is the error codes coming out of notify.<br>
Apart from producing some log messages, I can’t think how it would produce any recovery.<br>
<br>
Unless you’re relying on the subsequent monitor operation to notice the error state.<br>
I guess that would work but you might be waiting a while for it to notice.<br>
<div class="HOEnZb"><div class="h5"><br>
><br>
> On Wed, Nov 11, 2015 at 2:12 PM, Andrew Beekhof <<a href="mailto:abeekhof@redhat.com">abeekhof@redhat.com</a>> wrote:<br>
><br>
> > On 11 Nov 2015, at 6:26 PM, <a href="mailto:bdobrelia@mirantis.com">bdobrelia@mirantis.com</a> wrote:<br>
> ><br>
> > Thank you Andrew.<br>
> > Answers below.<br>
> > >>><br>
> > Sounds interesting, can you give any comment about how it differs to the other[i] upstream agent?<br>
> > Am I right that this one is effectively A/P and wont function without some kind of shared storage?<br>
> > Any particular reason you went down this path instead of full A/A?<br>
> ><br>
> > [i]<br>
> > <a href="https://github.com/ClusterLabs/resource-agents/blob/master/heartbeat/rabbitmq-cluster" rel="noreferrer" target="_blank">https://github.com/ClusterLabs/resource-agents/blob/master/heartbeat/rabbitmq-cluster</a><br>
> > <<<<br>
> > It is based on multistate clone notifications. It requries nothing shared but Corosync info base CIB where all Pacemaker resources stored anyway.<br>
> > And it is fully A/A.<br>
><br>
> Oh!  So I should skip the A/P parts before "Auto-configuration of a cluster with a Pacemaker”?<br>
> Is the idea that the master mode is for picking a node to bootstrap the cluster?<br>
><br>
> If so I don’t believe that should be necessary provided you specify ordered=true for the clone.<br>
> This allows you to assume in the agent that your instance is the only one currently changing state (by starting or stopping).<br>
> I notice that <a href="http://rabbitmq.com" rel="noreferrer" target="_blank">rabbitmq.com</a> explicitly sets this to false… any particular reason?<br>
><br>
><br>
> Regarding the pcs command to create the resource, you can simplify it to:<br>
><br>
> pcs resource create --force --master p_rabbitmq-server ocf:rabbitmq:rabbitmq-server-ha \<br>
>   erlang_cookie=DPMDALGUKEOMPTHWPYKC node_port=5672 \<br>
>   op monitor interval=30 timeout=60 \<br>
>   op monitor interval=27 role=Master timeout=60 \<br>
>   op monitor interval=103 role=Slave timeout=60 OCF_CHECK_LEVEL=30 \<br>
>   meta notify=true ordered=false interleave=true master-max=1 master-node-max=1<br>
><br>
> If you update the stop/start/notify/promote/demote timeouts in the agent’s metadata.<br>
><br>
><br>
> Lines 1602,1565,1621,1632,1657, and 1678 have the notify command returning an error.<br>
> Was this logic tested? Because pacemaker does not currently support/allow notify actions to fail.<br>
> IIRC pacemaker simply ignores them.<br>
><br>
> Modifying the resource state in notifications is also highly unusual.<br>
> What was the reason for that?<br>
><br>
> I notice that on node down, this agent makes disconnect_node and forget_cluster_node calls.<br>
> The other upstream agent does not, do you have any information about the bad things that might happen as a result?<br>
><br>
> Basically I’m looking for what each option does differently/better with a view to converging on a single implementation.<br>
> I don’t much care in which location it lives.<br>
><br>
> I’m CC’ing the other upstream maintainer, it would be good if you guys could have a chat :-)<br>
><br>
> > All running rabbit nodes may process AMQP connections. Master state is only for a cluster initial point at wich other slaves may join to it.<br>
> > Note, here you can find events flow charts as well [0]<br>
> > [0] <a href="https://www.rabbitmq.com/pacemaker.html" rel="noreferrer" target="_blank">https://www.rabbitmq.com/pacemaker.html</a><br>
> > Regards,<br>
> > Bogdan<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>
> 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>
> 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.com" rel="noreferrer" target="_blank">www.mirantis.com</a><br>
> <a href="http://www.mirantis.ru" rel="noreferrer" target="_blank">www.mirantis.ru</a><br>
> <a href="mailto:vkuklin@mirantis.com">vkuklin@mirantis.com</a><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>
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><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>