Description of problem: FFU: Launching an instance post upgrade when Nova services are running on a different role than controllers fails Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. Deploy OSP10 with 3 controllers + 2 serviceapi + 2 computes + 3 ceph nodes; controllers are running pacemaker managed services only and serviceapi nodes are running systemd managed services(including all nova services) 2. Upgrade the environment via FFU procedure 3. Once upgrade completes successful launch an instance on the overcloud Actual results: Instance fails to start. Expected results: Instance start successfully. Additional info: Attaching links to job and artifacts including logs.
This bug is marked for inclusion in the errata but does not currently contain draft documentation text. To ensure the timely release of this advisory please provide draft documentation text for this bug as soon as possible. If you do not think this bug requires errata documentation, set the requires_doc_text flag to "-". To add draft documentation text: * Select the documentation type from the "Doc Type" drop down field. * A template will be provided in the "Doc Text" field based on the "Doc Type" value selected. Enter draft text in the "Doc Text" field.
We were able to reproduce authentication issues even without FFU. After some debugging, it seems that depending on the service composition/ordering in roles data, sometimes Nova can end up with: "nova::keystone::authtoken::auth_url": "http://192.168.24.10:35357" while all other services have: "swift::proxy::authtoken::auth_url": "http://172.17.1.10:5000" This looks like a missing backport.
Backport posted: https://review.openstack.org/#/c/600444/
The fix is on the gate.
Master gate though :) I'll be backporting to Rocky when it lands to master.
Included in upstream t-h-t 8.0.7 so this must have gone in with the rebase, setting to MODIFIED.
The issue is still present, I'm wondering if this is not related to https://bugzilla.redhat.com/1626140
(In reply to Marius Cornea from comment #26) > The issue is still present, I'm wondering if this is not related to > https://bugzilla.redhat.com/1626140 Is there any workaround for this issue? Should this be considered a blocker for shipping osp13 next z-stream update? Thanks.
(In reply to Steve Linabery from comment #27) > (In reply to Marius Cornea from comment #26) > > The issue is still present, I'm wondering if this is not related to > > https://bugzilla.redhat.com/1626140 > > Is there any workaround for this issue? Should this be considered a blocker > for shipping osp13 next z-stream update? Thanks. There is no workaround for this issue. Given that this scenario has never worked properly I don't think it should be considered a blocker.
According to our records, this should be resolved by openstack-tripleo-heat-templates-8.3.1-79.el7ost. This build is available now.