Bug 1466878 - OSP9 minor update: the new ServiceNetMap from overcloud.yaml is not used
Summary: OSP9 minor update: the new ServiceNetMap from overcloud.yaml is not used
Keywords:
Status: CLOSED WORKSFORME
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: openstack-tripleo-common
Version: 9.0 (Mitaka)
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: ---
: ---
Assignee: Sofer Athlan-Guyot
QA Contact: Yurii Prokulevych
URL:
Whiteboard:
Depends On:
Blocks: 1464504 1539769 1539770
TreeView+ depends on / blocked
 
Reported: 2017-06-30 15:45 UTC by Ollie Walsh
Modified: 2020-08-13 09:35 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-10-02 10:19:01 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Ollie Walsh 2017-06-30 15:45:21 UTC
Description of problem:
During OSP9 minor update, the default ServiceNetMap parameter from overcloud.yaml in tripleo-heat-templates was not used. As a result network mapping were missing and the generated hieradata was incorrect.

Version-Release number of selected component (if applicable):
[stack@director ~]$ rpm -qa | grep puppet
puppet-3.6.2-2.el7.noarch
openstack-puppet-modules-8.1.13-2.el7ost.noarch
openstack-tripleo-puppet-elements-2.0.0-6.el7ost.noarch
[stack@director ~]$ rpm -qa | grep tripleo
openstack-tripleo-image-elements-0.9.9-7.el7ost.noarch
openstack-tripleo-0.0.8-0.2.d81bd6dgit.el7ost.noarch
openstack-tripleo-heat-templates-liberty-2.0.0-57.el7ost.noarch
openstack-tripleo-puppet-elements-2.0.0-6.el7ost.noarch
python-tripleoclient-2.0.0-14.el7ost.noarch
openstack-tripleo-heat-templates-2.0.0-57.el7ost.noarch
openstack-tripleo-common-2.0.0-10.el7ost.noarch
[stack@director ~]$ 

How reproducible:
Could not reproduce.

Actual results:
The generated sshd_config on compute nodes was invalid due to missing hieradata.

Expected results:
Successful update.

Additional info:
Forked from https://bugzilla.redhat.com/show_bug.cgi?id=1463680.
The update procedure was not followed correctly. A scale-out deployment was run after updating the undercloud but before updating the overcloud. A number of manual fixes were attempted to restore the overcloud to a good state. This may not be significant however.

Comment 1 Amit Ugol 2017-07-27 08:20:54 UTC
I see that the portal issue is closed, can we close this bug?

Comment 2 Ollie Walsh 2017-07-27 11:02:09 UTC
I'd rather we had a root cause for this. We had to explicitly provide the correct ServiceNetMap in that case to workaround this.

Comment 4 Ollie Walsh 2017-08-30 19:10:57 UTC
Is it possible that at some point in the lifetime of that stack, ServiceNetMap had been explicitly set (e.g via an environment file) but not longer is, and this value is saved on the stack?

Comment 5 Sofer Athlan-Guyot 2017-09-28 11:03:41 UTC
Hi,

if it was savet at any time, then yes it's saved in the databse ( the env) forever .

I guess that could explain this one as well.  Could we close it?

Comment 6 Ollie Walsh 2017-09-28 11:08:41 UTC
Yea, can close it. I've seen other instances of this happening but in all cases there was a ServiceNetMap saved on the stack.


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