Bug 1268451
| 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> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | low | ||
| 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) | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| 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 19:24:03 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Ryan Wyse
2015-10-02 20:52:27 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. This bug did not make the OSP 8.0 release. It is being deferred to OSP 10. 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. 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 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. 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. :-( 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
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 |