Juniper Openstack

Bug #1716577
Comment #7

Comment 7 for bug 1716577

Revision history for this message

Abhay Joshi (abhayj) wrote on 2017-09-13:

From: Ignatious Johnson <email address hidden>
Date: Tuesday, September 12, 2017 at 11:36 PM
To: Sachchidanand Vaidya <email address hidden>, Kamlesh Parmar <email address hidden>, Sarathbabu Narasimhan <email address hidden>
Cc: Sachin Bansal <email address hidden>, Jeba Paulaiyan <email address hidden>, Abhay Joshi <email address hidden>, Rudra Rugge <email address hidden>
Subject: Re: Bug #1716577

Hi Sachchidanand,

Kamlesh explained it clearly as below,

force_boot

Ensure that the node will start next time, even if it was not the last to shut down.
Normally when you shut down a RabbitMQ cluster altogether, the first node you restart should be the last one to go down, since it may have seen things happen that other nodes did not. But sometimes that's not possible: for instance if the entire cluster loses power then all nodes may think they were not the last to shut down.
In such a case you can invoke rabbitmqctl force_boot while the node is down. This will tell the node to unconditionally start next time you ask it to. If any changes happened to the cluster after this node shut down, they will be lost.
If the last node to go down is permanently lost then you should use rabbitmqctl forget_cluster_node --offline in preference to this command, as it will ensure that mirrored queues which were mastered on the lost node get promoted.
For example:
rabbitmqctl force_boot
This will force the node not to wait for other nodes next time it is started.

Possible customer cases follows,

1. setup where SM provisioned openstack node/rabbitmq and also controller container in same nodes. - only in our lab
2. Customer will not provision rabbit in same node, when using external rabbitmq server ( they will maintian a separate rabbit cluster and mange power outage properly)
3. Customer can skip external rabbitmq server and provison/use rabbit in controller container, in this case when controller nodes reboots, the ansible-internal-playbook will cluster/start the rabbitmq properly.

So we don’t need to worry about this bug.

Thanks,
Ignatious

From: Ignatious Johnson <ijohnson@juniper.net>
Date: Tuesday, September 12, 2017 at 11:36 PM
To: Sachchidanand Vaidya <vaidyasd@juniper.net>, Kamlesh Parmar <kparmar@juniper.net>, Sarathbabu Narasimhan <nsarath@juniper.net>
Cc: Sachin Bansal <sbansal@juniper.net>, Jeba Paulaiyan <jebap@juniper.net>, Abhay Joshi <abhayj@juniper.net>, Rudra Rugge <rrugge@juniper.net>
Subject: Re: Bug #1716577

Hi Sachchidanand,

Kamlesh explained it clearly  as below,

force_boot
 
Ensure that the node will start next time, even if it was not the last to shut down.
Normally when you shut down a RabbitMQ cluster altogether, the first node you restart should be the last one to go down, since it may have seen things happen that other nodes did not. But sometimes that's not possible: for instance if the entire cluster loses power then all nodes may think they were not the last to shut down.
In such a case you can invoke rabbitmqctl force_boot while the node is down. This will tell the node to unconditionally start next time you ask it to. If any changes happened to the cluster after this node shut down, they will be lost.
If the last node to go down is permanently lost then you should use rabbitmqctl forget_cluster_node --offline in preference to this command, as it will ensure that mirrored queues which were mastered on the lost node get promoted.
For example:
rabbitmqctl force_boot
This will force the node not to wait for other nodes next time it is started.

Possible customer cases follows,

So we don’t need to worry about this bug.

Thanks,
Ignatious