Hide Forgot
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:
Created attachment 1240362 [details] heat event list
Looking for what information you need to before wiping the QE Test.
Adding alifshit@redhat.com as well in case some nova side assistance would help.
If the firstboot script has been modified then you have probably hit https://bugzilla.redhat.com/show_bug.cgi?id=1385190
If you can reproduce this and post the Nova logs (with debug enabled) I'd be happy to take a look.
(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?
(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!
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.
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
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,
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,
Hi, Closing this one. Don't hesitate to re-open it if there is still an issue.
This can be closed.