Bug 1324546 - Corosync fails to start on one of the controllers in an upgraded 7.3->8 IPv6 environment
Summary: Corosync fails to start on one of the controllers in an upgraded 7.3->8 IPv6 ...
Keywords:
Status: CLOSED DUPLICATE of bug 1245951
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: rhosp-director
Version: 8.0 (Liberty)
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: ---
: 8.0 (Liberty)
Assignee: Angus Thomas
QA Contact: Arik Chernetsky
URL:
Whiteboard:
Depends On: 1245951
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-04-06 15:17 UTC by Marius Cornea
Modified: 2017-02-22 12:08 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: Known Issue
Doc Text:
Cause: Corosync sometimes fails to start correctly in IPv6 environments Consequence: Corosync can fail to start on reboot of controller nodes Workaround (if any): On reboot of the controller nodes, when the host comes back up, check for corosync status. If it failed, start the following services manually and in the following order: corosync, pacemaker, pcsd Result: The corosync service and related cluster services should come up correctly when restarted.
Clone Of:
Environment:
Last Closed: 2017-02-22 12:08:33 UTC
Target Upstream Version:


Attachments (Terms of Use)
corosync fail (15.97 KB, text/plain)
2016-04-06 15:17 UTC, Marius Cornea
no flags Details

Description Marius Cornea 2016-04-06 15:17:40 UTC
Created attachment 1144242 [details]
corosync fail

Description of problem:
After reboot corosync fails to start on one of the controllers in an upgraded 7.3->8 IPv6 environment.

Steps to Reproduce:
1. Upgrade overcloud from 7.3->8
2. Once the upgrade is complete reboot the controllers serially

Actual results:
Corosync failed to start when rebooting the last controller.

Expected results:
All the controllers get back online after reboot. 

Additional info:
The issue I am seeing looks pretty similar to the one describe by BZ#1245951

I am attaching the corosync log on the failed controller.

Comment 6 Mike Burns 2016-04-07 21:36:02 UTC
This bug did not make the OSP 8.0 release.  It is being deferred to OSP 10.

Comment 7 Mike Burns 2016-04-13 14:50:09 UTC
Moving back to 8.  This isn't targeted for a specific milestone because we're dependent on a RHEL bug fix, but once it's fixed, this will become testonly.

Comment 10 Fabio Massimo Di Nitto 2017-02-22 12:08:33 UTC

*** This bug has been marked as a duplicate of bug 1245951 ***


Note You need to log in before you can comment on or make changes to this bug.