Bug 1268451 - [RFE] Improve unspecified value for admin_vip in undercloud.conf
Summary: [RFE] Improve unspecified value for admin_vip in undercloud.conf
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: instack-undercloud
Version: 7.0 (Kilo)
Hardware: Unspecified
OS: Unspecified
Target Milestone: Upstream M3
: 11.0 (Ocata)
Assignee: Ben Nemec
QA Contact: Gurenko Alex
Depends On:
TreeView+ depends on / blocked
Reported: 2015-10-02 20:52 UTC by Ryan Wyse
Modified: 2017-05-17 19:24 UTC (History)
19 users (show)

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.
Clone Of:
Last Closed: 2017-05-17 19:24:03 UTC
Target Upstream Version:

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
OpenStack gerrit 400364 0 None None None 2016-11-22 15:30:30 UTC
Red Hat Product Errata RHEA-2017:1245 0 normal SHIPPED_LIVE Red Hat OpenStack Platform 11.0 Bug Fix and Enhancement Advisory 2017-05-17 23:01:50 UTC

Description Ryan Wyse 2015-10-02 20:52:27 UTC
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  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
2. undercloud$ openstack-config --set undercloud.conf DEFAULT local_interface eth0
3. undercloud$ openstack-config --set undercloud.conf DEFAULT masquerade_network
4. undercloud$ openstack-config --set undercloud.conf DEFAULT dhcp_start
5. undercloud$ openstack-config --set undercloud.conf DEFAULT dhcp_end
6. undercloud$ openstack-config --set undercloud.conf DEFAULT network_cidr
7. undercloud$ openstack-config --set undercloud.conf DEFAULT network_gateway
8. undercloud$ openstack-config --set undercloud.conf DEFAULT discovery_iprange,
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 17:33:13 UTC
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 20:54:03 UTC
This bug did not make the OSP 8.0 release.  It is being deferred to OSP 10.

Comment 8 Ben Nemec 2016-09-30 15:37:12 UTC
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 13:01:05 UTC
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 15:30:31 UTC
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-23 00:01:19 UTC
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 21:36:03 UTC
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

#image_path = .
local_ip =
network_gateway =
#undercloud_public_vip =
undercloud_service_certificate = /etc/pki/instack-certs/undercloud.pem
#undercloud_admin_vip =
local_interface = eth0
local_mtu = 1500
network_cidr =
masquerade_network =
dhcp_start =
dhcp_end =
inspection_interface = br-ctlplane
inspection_iprange =,

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 brd scope global br-ctlplane
       valid_lft forever preferred_lft forever
    inet scope global br-ctlplane
       valid_lft forever preferred_lft forever
    inet 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 19:24:03 UTC
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.


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