Bug 1427569
Summary: | OSP10 -> OSP11 upgrade fails when Nova services are running on a standalone node | ||
---|---|---|---|
Product: | Red Hat OpenStack | Reporter: | Marius Cornea <mcornea> |
Component: | openstack-tripleo-heat-templates | Assignee: | Sofer Athlan-Guyot <sathlang> |
Status: | CLOSED ERRATA | QA Contact: | Marius Cornea <mcornea> |
Severity: | urgent | Docs Contact: | |
Priority: | unspecified | ||
Version: | 11.0 (Ocata) | CC: | aschultz, dbecker, jcoufal, jschluet, mburns, morazi, panbalag, rhel-osp-director-maint, sathlang, slinaber |
Target Milestone: | rc | Keywords: | Triaged |
Target Release: | 11.0 (Ocata) | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | openstack-tripleo-heat-templates-6.0.0-4.el7ost | Doc Type: | If docs needed, set a value |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2017-05-17 20:02:33 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Marius Cornea
2017-02-28 16:00:27 UTC
Got a successful run in CI, so moving this one to POST. Checking if it's still working with the latest puddle. (In reply to Sofer Athlan-Guyot from comment #2) > Got a successful run in CI, so moving this one to POST. Checking if it's > still working with the latest puddle. I wasn't able to reproduce this issue with latest puddle. I think we're good on this one. Adding compute for visibility. Removing compute, as it's unrelated. The pcs cluster is not started making the database migration failed as the vip configured in nova::cell0_database_connection isn't reachable. But this is happening at step5 while all the database should be back in step4. Hi, so the upgrade of the custom role novacontrol is happening at the same time than the upgrade of the controller node: I prefix Novacontrol with N and controller logs with C: - C: step0: Apr 03 09:08:55 - N: step0: Apr 03 09:07:36 - N: step1: Apr 03 09:08:27 - N: step2: Apr 03 09:08:52 - C: step1: Apr 03 09:13:56 - N: step3: Apr 03 09:14:24 - N: step4: Apr 03 09:14:40 - C: step2: Apr 03 09:15:01 - N: step5: Apr 03 09:17:28 - C: step3: Apr 03 09:20:48 - C: step4: never happened - C: step5: never happened So the Novacontrol role got the time to reach the step5 while the controller was still at step3. We shouldn't have this kind of intermixed upgrade happening. Will check further on why this happen. In stable/ocata. Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHEA-2017:1245 |