instack-undercloud is no longer in use by the TripleO project. Removing
the code to avoid confusion. Stable branches will continue to be
maintained for their life however no new features should be added.
Change-Id: I63a813c7c1ffd30ca30017133d31a497b77a9a4d
Blueprint: remove-instack-undercloud
Add a validation, if the config have multiple subnets
specified but routed networks is disabled we raise
validation error.
Change-Id: Ic7ca1fb76e73da70f6a72100a9cbff42d8f34b0d
Masquerading for external access for each routed
network, if enabled.
Implements: blueprint tripleo-routed-networks-ironic-inspector
Implements: blueprint tripleo-routed-networks-deployment
Change-Id: I792b516314302e2c290e63c10fb0fe6881ce7236
Use groups to specify control plane network data. When
we do routed networks we need to provide network data
for each controlplane network/subnet.
Implements: blueprint tripleo-routed-networks-ironic-inspector
Implements: blueprint tripleo-routed-networks-deployment
Change-Id: Ia95ff5c00433c89155727ea5551904c45197e6b0
In this case an additional architecture is any architecture that is NOT
the same as the one running the install.
Blueprint: multiarch-support
Change-Id: I23f438cb41ebc454d4a4351901a86452e2b0d482
In order to improve the user experiance, we should validate that the
provided local_interface actually exists prior to trying to configure
the undercloud with it. If net_config_override is not used and the
local_interface does not exist, an error will be returned to the
user early on in the installation process. Additionally if the user
does not have an undercloud.conf, a warning is printed to show that
the defaults will be used.
Change-Id: Ia2a7e7fc916f6d2b62e212cb42641494b88d6d17
Closes-Bug: #1709177
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
When generate_service_certificate is True,
undercloud_service_certificate will not necessarily be set when it
is passed to validation. We need to check if either value is set
when deciding whether to validate vips.
Unit tests for this behavior were missing as well, so those have
been added.
Another consideration for this change is that we have started
passing non-IP values to these vip parameters when configuring
ssl. This is counterintuitive, but apparently works as intended
so let's just rename the parameters and handle both IPs and DNS
names for those values.
Change-Id: I53151d4f555d5d161a3e53ce5f022e3bf3b2ffbd
Closes-Bug: 1643655
This adds an undercloud_nameserver option which will be taken into
account in os-net-config to set up the undercloud's nameserver. If left
unset, it will give an empty list to the dns_servers parameter in
os-net-config, which will actually do nothing. If set, it will use that
nameserver as the sole member of a list that is passed to the
aforementioned parameter.
Co-Authored-By: Juan Antonio Osorio Robles <jaosorior@redhat.com>
Change-Id: I2b8a3f64dc1958f00b0471b68ba8283da76a4e7b
Remove deprecated network range 192.0.2.0 from undercloud
and use 192.168.24.0 as a default.
See also patch in CI: https://review.openstack.org/#/c/395529/
Change-Id: I1393d65ffb20b1396ff068def237418958ed3289
Depends-On: I73e657d9612ca843dd9e9980b0996658195c2dd7
This is a non-routable CIDR per RFC 5737, so we shouldn't be using
it by default. However, if we just change it and don't provide a
deprecation period we may break users who have deployed with the
default CIDR, so we should give them a cycle to update their
configs appropriately.
This changes the default of network_cidr to None so that we can
detect when a user has not changed our default, and sets the
appropriate override to maintain backwards compatibility in that
case. It also prints a warning about the deprecation at the end
of the deploy process, when it is most likely to be noticed.
Change-Id: I931a1f7160a007d367621de5cc1034c56c7741cf
Partial-Bug: 1553222
There are circumstances where an opt may be set to a legal value
that will error in non-obvious ways. Two of these are setting
local_ip to a non-CIDR-ish value which returns a cryptic netaddr
error, and using a non-FQDN for the undercloud hostname which will
cause failures later in the install.
This change adds validations to catch both of these cases.
Change-Id: Ied9b5ffaff18e2a405443a00b35ca53735c46024
Pulls in the validation portion of
https://github.com/cybertron/tripleo-scripts/blob/master/undercloud_wizard.py
and runs it on the undercloud configuration before starting
installation. This should catch a number of common mistakes when
configuring the undercloud, including addresses that do not fall
in the specified CIDR and misconfigured DHCP ranges.
Since we've now added a number of similar validation steps, I also
went ahead and combined them all into one call to clean up the
install() function a bit.
The wizard UI will be coming in a follow-up commit.
Change-Id: I08a2a8e2ea6bb8fcf92bba168720d5c4cafe1d18
Alex Schultz