Mirantis OpenStack

[RabbitMQ] need to deprecate commands "service rabbitmq-server stop" and "service rabbitmq-server start"

  1. Series 10.0.x
  2. Bug #1529639
Bug #1529639 reported by Timur Nurlygayanov
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Mirantis OpenStack
Status tracked in 10.0.x
10.0.x
Confirmed
Medium
MOS Oslo
Mirantis OpenStack 10.0
8.0.x
Won't Fix
Medium
MOS Oslo
Mirantis OpenStack 8.0
9.x
Confirmed
Medium
MOS Oslo
Mirantis OpenStack 9.x-updates

Bug Description

We need to deprecate commands "service rabbitmq-server stop" and "service rabbitmq-server start" because these commands don't work and broke RabbitMQ cluster. We need to use pacemaker instead and restart Rabbit MQ services with the following commands:

pcs resource disable p_rabbitmq-server
pcs resource enable p_rabbitmq-server

Steps To Reproduce:
1) Restart RabbitMQ using "service" command:
service rabbitmq-server stop
service rabbitmq-server start
2) Check RabbitMQ status in pacemaker.

Actual Result:
RabbitMQ cluster brocken and pacemaker can't start RabbitMQ on this node, because 'service rabbitmq-server start' will remove and change pid of the process.

Expected Result:
Commands 'service rabbitmq-server start' and 'service rabbitmq-server stop' are not available of controllers and it is possible to restart RabbitMQ only with pacemaker.

The issue reproduced on 7.0, 8.0 and 9.0 versions.

See original description
Timur Nurlygayanov (tnurlygayanov)
Changed in mos:
importance: Undecided → Medium
assignee: nobody → Dmitry Mescheryakov (dmitrymex)
Revision history for this message
Eugene Nikanorov (enikanorov) wrote :

Hmm, how are we going to 'deprecate' those?
Should we just avoid using those commands?

Timur Nurlygayanov (tnurlygayanov)
Changed in mos:
milestone: 8.0 → none
assignee: Dmitry Mescheryakov (dmitrymex) → nobody
importance: Medium → Undecided
Dmitry Mescheryakov (dmitrymex)
Changed in mos:
status: New → Confirmed
importance: Undecided → Medium
assignee: nobody → Dmitry Mescheryakov (dmitrymex)
milestone: none → 9.0
assignee: Dmitry Mescheryakov (dmitrymex) → MOS Oslo (mos-oslo)
Revision history for this message
Bug Checker Bot (bug-checker) wrote : Autochecker

(This check performed automatically)
Please, make sure that bug description contains the following sections filled in with the appropriate data related to the bug you are describing:

actual result

version

expected result

steps to reproduce

For more detailed information on the contents of each of the listed sections see https://wiki.openstack.org/wiki/Fuel/How_to_contribute#Here_is_how_you_file_a_bug

tags: added: need-info
Timur Nurlygayanov (tnurlygayanov)
description: updated
Bug Checker Bot (bug-checker)
tags: removed: need-info
Fuel Devops McRobotson (fuel-devops-robot)
Changed in mos:
status: Confirmed → Won't Fix
Revision history for this message
Alexey Lebedeff (alebedev-a) wrote :

There were some changes to prevent rabbitmq from starting during package installation. So 'deprecation' is a next step - we just need to remove init/upstart/systemd stuff from packages completely. The question is what we should do with Fuel master node, which also depends on rabbit. Or it's safe to assume that master node is always centos, and controllers are always trusty?

Revision history for this message
Timur Nurlygayanov (tnurlygayanov) wrote :

I think it will be true for 8.0-10.0 releases but it can be changed in the future.

Revision history for this message
Dina Belova (dbelova) wrote :

Added move-to-10.0 tag due to the fact bug was transferred from 9.0 to 10.0

tags: added: move-to-10.0
Dmitry Mescheryakov (dmitrymex)
Changed in mos:
status: Won't Fix → Confirmed
milestone: 9.0 → 9.1
tags: added: 10.0-reviewed
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.