Disable VIP validation when UI is enabled

The UI needs to be accessible from outside the undercloud, which in
many cases means it can't be listening on the provisioning network
because that network is often not routable.

This is somewhat unfortunate because we also have reports that
moving the VIP outside the provisioning network can break
installation[1], but we have two conflicting requirements here and
the UI takes precedence.  Hopefully if the referenced bug reoccurs
as a result of this change we can investigate further and find a
way to validate that doesn't break the UI.

Change-Id: If4e77e3b6fc8444569c2a4672bd270e249436a73
1: https://bugzilla.redhat.com/show_bug.cgi?id=1268451
Closes-Bug: 1668180
This commit is contained in:
Ben Nemec 2017-03-23 15:23:28 +00:00
parent 9f23fbda47
commit dc14935f9f
3 changed files with 35 additions and 5 deletions

View File

@ -132,22 +132,30 @@ class TestValidator(base.BaseTestCase):
def test_fail_on_invalid_public_host(self):
self.conf.config(undercloud_public_host='192.0.3.2',
undercloud_service_certificate='foo.pem')
undercloud_service_certificate='foo.pem',
enable_ui=False)
self.assertRaises(validator.FailedValidation,
undercloud._validate_network)
def test_fail_on_invalid_admin_host(self):
self.conf.config(undercloud_admin_host='192.0.3.3',
generate_service_certificate=True)
generate_service_certificate=True,
enable_ui=False)
self.assertRaises(validator.FailedValidation,
undercloud._validate_network)
def test_ssl_hosts_allowed(self):
self.conf.config(undercloud_public_host='public.domain',
undercloud_admin_host='admin.domain',
undercloud_service_certificate='foo.pem')
undercloud_service_certificate='foo.pem',
enable_ui=False)
undercloud._validate_network()
def test_allow_all_with_ui(self):
self.conf.config(undercloud_admin_host='10.0.0.10',
generate_service_certificate=True,
enable_ui=True)
def test_fail_on_invalid_ip(self):
self.conf.config(dhcp_start='foo.bar')
self.assertRaises(validator.FailedValidation,

View File

@ -93,8 +93,13 @@ def _validate_in_cidr(params, error_callback):
params['inspection_end'] = inspection_iprange[1]
validate_addr_in_cidr(params, 'just_local_ip', 'local_ip')
validate_addr_in_cidr(params, 'network_gateway')
if (params['undercloud_service_certificate'] or
params['generate_service_certificate']):
# NOTE(bnemec): The ui needs to be externally accessible, which means in
# many cases we can't have the public vip on the provisioning network.
# In that case users are on their own to ensure they've picked valid
# values for the VIP hosts.
if ((params['undercloud_service_certificate'] or
params['generate_service_certificate']) and
not params['enable_ui']):
validate_addr_in_cidr(params, 'undercloud_public_host',
require_ip=False)
validate_addr_in_cidr(params, 'undercloud_admin_host',

View File

@ -0,0 +1,17 @@
---
fixes:
- |
Previously, when an IP value was provided for the undercloud_public_host
or undercloud_admin_host config value, it was validated to ensure it fell
within the network_cidr. This was to avoid problems when the CIDR was
changed but the IPs were not. However, this validation was broken for a
time in the case where generate_service_certificate was used. During this
time, the UI began to depend on the broken validation as it needs to
listen on a routable network, which the provisioning network often is not.
When the validation was fixed, the user was no longer able to configure
the host values to listen on a different routable network.
To enable this UI functionality again, the host validation has been
disabled when enable_ui is true. This means the user is responsible for
selecting functional host values, but the UI can once again be configured
to listen on a separate network.