Bug 1413070 - Upgrade OSP 8 to OSP 9 - Failed to detach interfaces
Summary: Upgrade OSP 8 to OSP 9 - Failed to detach interfaces
Keywords:
Status: CLOSED WORKSFORME
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: rhosp-director
Version: 8.0 (Liberty)
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: ---
: ---
Assignee: Sofer Athlan-Guyot
QA Contact: Amit Ugol
URL:
Whiteboard:
Depends On:
Blocks: 1305654
TreeView+ depends on / blocked
 
Reported: 2017-01-13 14:37 UTC by Randy Perryman
Modified: 2020-12-21 19:44 UTC (History)
18 users (show)

Fixed In Version: openstack-tripleo-common-2.0.0-9.el7ost
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-05-02 17:50:36 UTC
Target Upstream Version:


Attachments (Terms of Use)
Log of the error (21.25 KB, text/plain)
2017-01-13 14:37 UTC, Randy Perryman
no flags Details
heat event list (902.54 KB, text/plain)
2017-01-13 14:37 UTC, Randy Perryman
no flags Details
Nova logs from Audra's config (1.73 MB, application/zip)
2017-01-19 19:40 UTC, Audra Cooper
no flags Details

Description Randy Perryman 2017-01-13 14:37:32 UTC
Created attachment 1240361 [details]
Log of the error

Description of problem:
Running the Upgrade steps and on the Controller Upgrade (-e ~/pilot/templates/overcloud/environments/major-upgrade-pacemaker.yaml), step we are getting the error:

2017-01-12 23:55:33 [CephStorage]: UPDATE_FAILED InterfaceDetachFailed: resources.CephStorage: Failed to detach interface (7346baed-1f22-4f31-b441-1f2bc57432c4) from server (5e178a20-e9d4-4fa0-8960-23e6bf6a3248)
2017-01-12 23:55:44 [overcloud-Compute-fldcgzzj4xsi-2-xa3kahkz4pah]: UPDATE_FAILED InterfaceDetachFailed: resources.NovaCompute: Failed to detach interface (0e99f2b9-dae7-47ee-9939-5cc524ad09d6) from server (7fb28ec0-615e-4f3a-8362-21843e291712)

Version-Release number of selected component (if applicable):
OSP 9 Upgrade from OSP 8

How reproducible:


Steps to Reproduce:
1. Install OSP 8 with Ceph, Dell PS and Dell SC backend.
2. Create Instances that boot from volumes on both PS, SC and Ceph volumes,
3. Create volumes on all storage and attach to the instances.  
4. Run the Update and Upgrade process https://access.redhat.com/documentation/en/red-hat-openstack-platform/9/paged/upgrading-red-hat-openstack-platform/chapter-3-director-based-environments-performing-upgrades-to-major-versions
Actual results:


Expected results:
OSP 9 installed and running


Additional info:

Comment 1 Randy Perryman 2017-01-13 14:37:58 UTC
Created attachment 1240362 [details]
heat event list

Comment 2 Randy Perryman 2017-01-16 16:46:30 UTC
Looking for what information you need to before wiping the QE Test.

Comment 3 Mike Orazi 2017-01-17 19:06:29 UTC
Adding alifshit@redhat.com as well in case some nova side assistance would help.

Comment 4 Dimitri Savineau 2017-01-17 19:42:43 UTC
If the firstboot script has been modified then you have probably hit https://bugzilla.redhat.com/show_bug.cgi?id=1385190

Comment 5 Artom Lifshitz 2017-01-17 20:02:41 UTC
If you can reproduce this and post the Nova logs (with debug enabled) I'd be happy to take a look.

Comment 6 Audra Cooper 2017-01-17 20:26:09 UTC
(In reply to Artom Lifshitz from comment #5)
> If you can reproduce this and post the Nova logs (with debug enabled) I'd be
> happy to take a look.

Hi Artom,
Do you want all of the nova logs on the controller and the nova-compute.log?  So I will set Nova.conf to debug on all of the controllers, restart the nova services and re-run upgrade?

Comment 7 Artom Lifshitz 2017-01-17 21:07:55 UTC
(In reply to Dimitri Savineau from comment #4)
> If the firstboot script has been modified then you have probably hit
> https://bugzilla.redhat.com/show_bug.cgi?id=1385190

In his email Randy was saying that this is the case. If that's indeed true I don't think there's much use obtaining Nova logs.

(In reply to Audra Cooper from comment #6)
> Do you want all of the nova logs on the controller and the nova-compute.log?
> So I will set Nova.conf to debug on all of the controllers, restart the nova
> services and re-run upgrade?

If my previous paragraph does not apply, then yes, the more logs the merrier :) Controller(s) and compute(s), all in debug mode. The procedure that you outline in your email is the correct one.

Cheers!

Comment 8 Audra Cooper 2017-01-19 18:43:09 UTC
Hi Sean, 

I should have responded to Artom above.  Randy's email stated this issue is related to bz 1385190.  I did capture nova logs if you want them though.

Comment 9 Audra Cooper 2017-01-19 19:40:45 UTC
Created attachment 1242556 [details]
Nova logs from Audra's config

I have all of the nova logs from each controller as well as each compute

Comment 10 Sofer Athlan-Guyot 2017-01-24 22:16:08 UTC
Waiting here to see if the patch provided openstack-tripleo-common-2.0.0-9.el7ost from bz https://bugzilla.redhat.com/show_bug.cgi?id=1385190 solves this issue (it should)

Regards,

Comment 11 Sofer Athlan-Guyot 2017-03-20 13:42:21 UTC
Hi Randy,

can you confirm that with tripleo-common > 2.0.0.9 you don't have the issue anymore, so that I close this bug as duplicato of 1385190.

Thanks,

Comment 13 Sofer Athlan-Guyot 2017-05-02 17:50:36 UTC
Hi,

Closing this one.  Don't hesitate to re-open it if there is still an issue.

Comment 14 Randy Perryman 2017-07-17 12:08:08 UTC
This can be closed.


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