Bug 1466878 - OSP9 minor update: the new ServiceNetMap from overcloud.yaml is not used
OSP9 minor update: the new ServiceNetMap from overcloud.yaml is not used
Product: Red Hat OpenStack
Classification: Red Hat
Component: openstack-tripleo-common (Show other bugs)
9.0 (Mitaka)
Unspecified Unspecified
high Severity high
: ---
: ---
Assigned To: Sofer Athlan-Guyot
Yurii Prokulevych
: Triaged, ZStream
Depends On:
Blocks: 1539770 1464504 1539769
  Show dependency treegraph
Reported: 2017-06-30 11:45 EDT by Ollie Walsh
Modified: 2018-01-29 10:05 EST (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2017-10-02 06:19:01 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Ollie Walsh 2017-06-30 11:45:21 EDT
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
[stack@director ~]$ rpm -qa | grep tripleo
[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 04:20:54 EDT
I see that the portal issue is closed, can we close this bug?
Comment 2 Ollie Walsh 2017-07-27 07:02:09 EDT
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 15:10:57 EDT
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 07:03:41 EDT

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 07:08:41 EDT
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.