<div dir="ltr">Actually, we are not skipping 'Started' state - we just consider resource as started when beam is powered up and rabbitmq start_app/stop_app action succeeds. Such a node is considered as a good one that can be marked as 'Master' to which the nodes should connect and then all the cluster join/leave actions are handled using multi-state notification mechanism. </div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, May 20, 2015 at 5:05 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"><div class="HOEnZb"><div class="h5"><br>
> On 20 May 2015, at 6:05 am, Andrew Woodward <<a href="mailto:xarses@gmail.com">xarses@gmail.com</a>> wrote:<br>
><br>
><br>
><br>
> On Thu, May 7, 2015 at 5:01 PM Andrew Beekhof <<a href="mailto:abeekhof@redhat.com">abeekhof@redhat.com</a>> wrote:<br>
><br>
> > On 5 May 2015, at 1:19 pm, Zhou Zheng Sheng / 周征晟 <<a href="mailto:zhengsheng@awcloud.com">zhengsheng@awcloud.com</a>> wrote:<br>
> ><br>
> > Thank you Andrew.<br>
> ><br>
> > on 2015/05/05 08:03, Andrew Beekhof wrote:<br>
> >>> On 28 Apr 2015, at 11:15 pm, Bogdan Dobrelya <<a href="mailto:bdobrelia@mirantis.com">bdobrelia@mirantis.com</a>> wrote:<br>
> >>><br>
> >>>> Hello,<br>
> >>> Hello, Zhou<br>
> >>><br>
> >>>> I using Fuel 6.0.1 and find that RabbitMQ recover time is long after<br>
> >>>> power failure. I have a running HA environment, then I reset power of<br>
> >>>> all the machines at the same time. I observe that after reboot it<br>
> >>>> usually takes 10 minutes for RabittMQ cluster to appear running<br>
> >>>> master-slave mode in pacemaker. If I power off all the 3 controllers and<br>
> >>>> only start 2 of them, the downtime sometimes can be as long as 20 minutes.<br>
> >>> Yes, this is a known issue [0]. Note, there were many bugfixes, like<br>
> >>> [1],[2],[3], merged for MQ OCF script, so you may want to try to<br>
> >>> backport them as well by the following guide [4]<br>
> >>><br>
> >>> [0] <a href="https://bugs.launchpad.net/fuel/+bug/1432603" target="_blank">https://bugs.launchpad.net/fuel/+bug/1432603</a><br>
> >>> [1] <a href="https://review.openstack.org/#/c/175460/" target="_blank">https://review.openstack.org/#/c/175460/</a><br>
> >>> [2] <a href="https://review.openstack.org/#/c/175457/" target="_blank">https://review.openstack.org/#/c/175457/</a><br>
> >>> [3] <a href="https://review.openstack.org/#/c/175371/" target="_blank">https://review.openstack.org/#/c/175371/</a><br>
> >>> [4] <a href="https://review.openstack.org/#/c/170476/" target="_blank">https://review.openstack.org/#/c/170476/</a><br>
> >> Is there a reason you’re using a custom OCF script instead of the upstream[a] one?<br>
> >> Please have a chat with David (the maintainer, in CC) if there is something you believe is wrong with it.<br>
> >><br>
> >> [a] <a href="https://github.com/ClusterLabs/resource-agents/blob/master/heartbeat/rabbitmq-cluster" target="_blank">https://github.com/ClusterLabs/resource-agents/blob/master/heartbeat/rabbitmq-cluster</a><br>
> ><br>
> > I'm using the OCF script from the Fuel project, specifically from the<br>
> > "6.0" stable branch [alpha].<br>
><br>
> Ah, I’m still learning who is who... i thought you were part of that project :-)<br>
><br>
> ><br>
> > Comparing with upstream OCF code, the main difference is that Fuel<br>
> > RabbitMQ OCF is a master-slave resource. Fuel RabbitMQ OCF does more<br>
> > bookkeeping, for example, blocking client access when RabbitMQ cluster<br>
> > is not ready. I beleive the upstream OCF should be OK to use as well<br>
> > after I read the code, but it might not fit into the Fuel project. As<br>
> > far as I test, the Fuel OCF script is good except sometimes the full<br>
> > reassemble time is long, and as I find out, it is mostly because the<br>
> > Fuel MySQL Galera OCF script keeps pacemaker from promoting RabbitMQ<br>
> > resource, as I mentioned in the previous emails.<br>
> ><br>
> > Maybe Vladimir and Sergey can give us more insight on why Fuel needs a<br>
> > master-slave RabbitMQ.<br>
><br>
> That would be good to know.<br>
> Browsing the agent, promote seems to be a no-op if rabbit is already running.<br>
><br>
><br>
> To the master / slave reason due to how the ocf script is structured to deal with rabbit's poor ability to handle its self in some scenarios. Hopefully the state transition diagram [5] is enough to clarify what's going on.<br>
><br>
> [5] <a href="http://goo.gl/PPNrw7" target="_blank">http://goo.gl/PPNrw7</a><br>
<br>
</div></div>Not really.<br>
It seems to be under the impression you can skip started and go directly from stopped to master.<br>
<div class="HOEnZb"><div class="h5">__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><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></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>