|Summary:||[RFE] Improve unspecified value for admin_vip in undercloud.conf|
|Product:||Red Hat OpenStack||Reporter:||Ryan Wyse <rwyse>|
|Component:||instack-undercloud||Assignee:||Ben Nemec <bnemec>|
|Status:||CLOSED ERRATA||QA Contact:||Gurenko Alex <agurenko>|
|Version:||7.0 (Kilo)||CC:||achernet, agurenko, aschultz, bfournie, bnemec, dtantsur, emacchi, jcoufal, jschluet, kbasil, lruzicka, mburns, nlevinki, rbartal, rhel-osp-director-maint, rwyse, sasha, sclewis, snozhka|
|Target Milestone:||Upstream M3||Keywords:||FutureFeature, Triaged|
|Target Release:||11.0 (Ocata)|
|Fixed In Version:||instack-undercloud-6.0.0-0.20170127055514.317db76.el7ost||Doc Type:||Bug Fix|
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.
|Last Closed:||2017-05-17 19:24:03 UTC||Type:||Bug|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
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 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 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  leads to successful undercloud installation, no any validation errors observed, but expected. Verified with instack-undercloud-5.1.0-2.el7ost.noarch.  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
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 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. https://access.redhat.com/errata/RHEA-2017:1245