This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 1268451 - [RFE] Improve unspecified value for admin_vip in undercloud.conf
[RFE] Improve unspecified value for admin_vip in undercloud.conf
Status: CLOSED ERRATA
Product: Red Hat OpenStack
Classification: Red Hat
Component: instack-undercloud (Show other bugs)
7.0 (Kilo)
Unspecified Unspecified
low Severity unspecified
: Upstream M3
: 11.0 (Ocata)
Assigned To: Ben Nemec
Gurenko Alex
: FutureFeature, Triaged
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-10-02 16:52 EDT by Ryan Wyse
Modified: 2017-05-17 15:24 EDT (History)
19 users (show)

See Also:
Fixed In Version: instack-undercloud-6.0.0-0.20170127055514.317db76.el7ost
Doc Type: Bug Fix
Doc Text:
In certain situations, the undercloud virtual IPs were not correctly validated due to an error in the validation logic. Consequently, the undercloud could be deployed with incorrect virtual IPs. The error has been fixed. Now the virtual IPs are correctly validated. Any problem in virtual IP configuration is discovered before actual deployment.
Story Points: ---
Clone Of:
Environment:
Last Closed: 2017-05-17 15:24:03 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
OpenStack gerrit 400364 None None None 2016-11-22 10:30 EST

  None (edit)
Description Ryan Wyse 2015-10-02 16:52:27 EDT
Description of problem:
At the moment if you don't specify and explicit value for undercloud_admin_vip in the undercloud.conf before you run the installation, it will default to the value of 192.0.2.0.  I have attempted 4-5 of deploys leaving this at default and all the deploys failed with a result of my having to completely rebuild the undercloud host.  Rather than having this default to that value, would be great if the installer would ask for explicit values before proceeding or even gracefully fail due to the lack of input.

Version-Release number of selected component (if applicable):
RHEL OSP Installer 7.0.

How reproducible:


Steps to Reproduce:
1.undercloud$ openstack-config --set undercloud.conf DEFAULT local_ip 172.16.0.1/24
2. undercloud$ openstack-config --set undercloud.conf DEFAULT local_interface eth0
3. undercloud$ openstack-config --set undercloud.conf DEFAULT masquerade_network 172.16.0.0/24
4. undercloud$ openstack-config --set undercloud.conf DEFAULT dhcp_start 172.16.0.20
5. undercloud$ openstack-config --set undercloud.conf DEFAULT dhcp_end 172.16.0.120
6. undercloud$ openstack-config --set undercloud.conf DEFAULT network_cidr 172.16.0.0/24
7. undercloud$ openstack-config --set undercloud.conf DEFAULT network_gateway 172.16.0.1
8. undercloud$ openstack-config --set undercloud.conf DEFAULT discovery_iprange 172.16.0.150,172.16.0.180
9. openstack undercloud install

Actual results:
Defaults to values specified in the undercloud.conf file which aren't necessarily going to be used in an actual deployment.

Expected results:
Install should either gracefully fail with error on missing input, or more desirable results would be for the installer to ask for the information explicitly if it is not indicated in the file.

Additional info:
Comment 2 Ben Nemec 2015-10-05 13:33:13 EDT
I would be curious what the actual failures are, because based on the information in this bug the VIPs won't even be used (they're only relevant to SSL-enabled underclouds), so they wouldn't likely be causing the problem.  Furthermore, it should be possible to change VIPs without reinstalling from scratch, so I think there's more going on here than bad VIP values.

That said, I completely agree we need to do more config validation.
Comment 6 Mike Burns 2016-04-07 16:54:03 EDT
This bug did not make the OSP 8.0 release.  It is being deferred to OSP 10.
Comment 8 Ben Nemec 2016-09-30 11:37:12 EDT
This isn't a hardware provisioning issue.  It's a configuration problem when installing the undercloud.

That said, it's fixed in OSP 10.  There are now validations in place to ensure the vips are on the correct subnet so if you forget to set one it will stop the installation.
Comment 13 Sergii Nozhka 2016-11-22 08:01:05 EST
Using configs provided in steps to reproduce [0] leads to successful undercloud installation, no any validation errors observed, but expected.

Verified with instack-undercloud-5.1.0-2.el7ost.noarch.


[0] http://pastebin.test.redhat.com/432557
Comment 14 Ben Nemec 2016-11-22 10:30:31 EST
A fix has been proposed to upstream master.  It will need to merge and get backported before this is completely fixed.

Note that the validation works correctly if you specify a service certificate.  It only fails if the undercloud is generating it.
Comment 15 Ben Nemec 2016-11-22 19:01:19 EST
It's not looking good for getting this fixed in OSP 10.  It turns out we added a feature that actually depends on this bug.  A proper fix is going to be invalid for backport because it involves retroactively deprecating a config opt. :-(
Comment 16 Alexander Chuzhoy 2016-11-24 16:36:03 EST
FailedQA:
Environmnet: instack-undercloud-5.1.0-3.el7ost.noarch

The "openstack undercloud install" command was supposed to exit with error with the following undercloud.conf (the undercloud_admin_vip is commented out):


[stack@undercloud-0 ~]$ cat undercloud.conf
[DEFAULT]

#image_path = .
local_ip = 192.0.2.1/24
network_gateway = 192.0.2.1
#undercloud_public_vip = 192.0.2.2
undercloud_service_certificate = /etc/pki/instack-certs/undercloud.pem
#undercloud_admin_vip = 192.0.2.3
local_interface = eth0
local_mtu = 1500
network_cidr = 192.0.2.0/24
masquerade_network = 192.0.2.0/24
dhcp_start = 192.0.2.5
dhcp_end = 192.0.2.24
inspection_interface = br-ctlplane
inspection_iprange = 192.0.2.100,192.0.2.120


Instead the undercloud deployment started and completed successfully.


10: br-ctlplane: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN qlen 1000
    link/ether 52:54:00:32:bc:09 brd ff:ff:ff:ff:ff:ff
    inet 192.0.2.1/24 brd 192.0.2.255 scope global br-ctlplane
       valid_lft forever preferred_lft forever
    inet 192.0.2.3/32 scope global br-ctlplane
       valid_lft forever preferred_lft forever
    inet 192.0.2.2/32 scope global br-ctlplane
       valid_lft forever preferred_lft forever
    inet6 fe80::5054:ff:fe32:bc09/64 scope link
       valid_lft forever preferred_lft forever
Comment 36 errata-xmlrpc 2017-05-17 15:24:03 EDT
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHEA-2017:1245

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