For each role create a network config resource
{role.name}}NetworkConfig. Remove per node
NetworkConfig resource from puppet/role.role.j2.yaml.
NOTE: CI nic config templates was updated with using
tools/merge-new-params-nic-config-script.py
Depends-On: https://review.opendev.org/753930
Change-Id: Iff4bf742947a5a8170938372a8075519850b6f63
This removes the run-os-net-config.sh script and uses
OS::Heat::Value for the NetworkConfig resources.
Depends-On: https://review.opendev.org/#/c/751713/
Change-Id: Ic3a0234d36525cdd6f415c77733d05a39bbeb3c2
This uses the new ansible module for network configuration
on the nodes. Aso, converts the net-config-multinode.yaml to
use os-net-config.
Next patch in this series would change the NetworkConfig
resource type to OS::Heat::Value and drop run-os-net-config.sh.
Depends-On: https://review.opendev.org/748754
Change-Id: Ie48da5cfffe21eee6060a6d22045d09524283138
Commit 1ebf115f85 hard code
the netmask for VIPs to /32. This will not work for IPv6.
Add a conditional checking for ':' in the IP addresses for
control_virtual_ip and public_virtual_ip and set netmask
correctly based on IP version.
Related-Bug: #1878101
Change-Id: I00718cf436ba438ef19c1a42aa2d2004fe73dcd2
Prior to commit c712355e4b
KeepaliveD created the VIP addresses. KeepaliveD created
the VIPs with /32 netmask, when moving the VIPs to the
DeployedServerPortMap and adding them to the br-ctlplane
interface the netmask of the ctlplane subnet was used
(typically /24). The result is a routing table that
potentially uses the incorrect device for traffic when
the public VIP is not on in the ctlplane subnet.
This change hard-codes the netmask for the VIP addresses
to /32.
blueprint replace-keepalived-undercloud
Closes-Bug: #1878101
Change-Id: I873e925d2250677f25b9ae51ed0b87bd1b8e6b32
We don't deploy Keepalived in multi-node as our HA story is done with
Pacemaker. Therefore, we don't use VRRP protocol that Keepalived
provides to maintain the VIPs alive, so we don't really need this
service.
Instead, we can configure the VIPs on the br-ctlplane interface which
already handled the local_ip. Now it also handles the configuration of
public ip and admin ip.
Keepalived is now deprecated and will be removed in the next cycle.
blueprint replace-keepalived-undercloud
Change-Id: I3192be07cb6c19d5e26cb4cddbe68213e7e48937
Since https://review.opendev.org/656581 is merged (and the revert,
reverting the revert ...) there is no metadata service running.
This change removes all things related to setting up routes
to the metadata service, i.e the EC2MetadataIp. As well as NAT
firewall redirect rule used only on the undercloud but disabled
by default.
Blueprint: nova-less-deploy
Change-Id: Ic4ea74b45c566048e32dde82d2bf00498f932af6
Set the br-ctlplane MTU to the InterfaceLocalMtu value. This is
required when multiple Standalone nodes are used in a split-stack
deployment.
Closes-Bug: #1823993
Change-Id: I84a35d529ee67e939db1cdadd103f88295e41e8f
Since https://review.openstack.org/645039, parameter
ExternalInterfaceDefaultRoute is passed to nic config
templates for roles with the default setting for
controller nodes 'default_route_networks: ['External']'
in roles data.
Add the parameter with '' default in tht/net-config-*
templates for compatibility.
Change-Id: I0f1a0893b6d3d400f51b218ae74ec64d876e0115
Previously all networks was rendered for all roles, and
thus the default set in network/network.j2#L83 would
propgate to the nic config for any role. Since we now
only include properties for network's in role.networks
when passing parameters puppet/role.role.j2.yaml this
default may not propagate to the nic config and can
cause problems if merge-new-params-nic-config-script.py
was used to add new parameters with a role missmatch.
(i.e Updating the Compute roles NIC config file while
specifying the Controller role in merge-new-params
tool would add the parameter with no default which
causes Property {{network.name}}Mtu not assigned
error when deploying.
Change-Id: I3031977a0daabb093cb8f61bcfc22b68e8e35bed
Neutron has support[1] to set the guaranteed MTU for
networks and network segments so that this is exposed
to plug-ins. In interest of supporting the use of
plug-ins to configure network devices in the future
this change adds MTU property on neutron networks.
The new (optional) property 'mtu' in the network
defenitions in 'network_data.yaml' is used to control
the MTU settings. By default the mtu is '1500'.
We already configure the MTU on the ctlplane neutron
networks, this adds the MTU to composable networks.
Also update the nic-config sample templates to include
mtu settings. A heat value resource is added to
nic-config templates to get the required minimum
viable MTU value for bridges, bonds and member
interfaces to ensure the MTU is large enough to allow
the largest configured MTU to traverse the path.
Closes-Bug: #1790537
Change-Id: I11e38f82eb9040f77412fe8ad200fcc48031e2f8
For the isolated networks we use the subnets host_routes
to set and get the routes for overcloud node interfaces.
This change add's this to the ctlplane interface.
Partial: blueprint tripleo-routed-networks-templates
Change-Id: Id4cf0cc17bc331ae27f8d0ef8f285050330b7be0
This change adds a new {{network.name}}InterfaceRoutes
parameter to network config templates. It takes a list
of routes i.e:
[{'destination':'10.0.0.0/16', 'nexthop':'10.0.0.1'}]
Co-Authored-By: Harald Jensås <hjensas@redhat.com>
Partial: blueprint tripleo-routed-networks-templates
Depends-On: Ifc5aad7a154c33488a7613c8ee038c92ee6cb1a7
Change-Id: I90aea46d3addab9792c7c9d4feff5c5f61520b9b
Nameservers are configured on the ctlplane subnets by the
undercloud installer, the nameservers are used early during
the deployment, prior to running os-net-config.
Remove the default DnsServer's in THT, replacing it with
an empty list and use get_attr to get the values for
DnsServers for the overcloud from the ctlplane subnet(s).
A conditinal is used in puppet/role.role.j2.yaml so that
the parameter value is used whenever it is not [] (default)
to provide backwards compatibilityi and in case the user
want to use different DnsServers for the overcloud and
undercloud.
Partial: blueprint tripleo-routed-networks-templates
Change-Id: I5f33e06ca3f4b13cc355e02156edd9d8a1f773cd
The route to metadata service is set up in host_routes
of ctlplane subnets by extraconf post deploy::
extraconfig/post_deploy/undercloud_ctlplane_network.py
Use get_attr on the server resource to resolve attribute
value from the subnet(s) and pass it to the parameter
'EC2MetadatIp' used in the THT/network/config/* templates.
Changes the default for 'EC2MetadatIp' to ''.
Removes the comment that the value should be overriden in
parameters_defaults. It also removes the parameter from
network-environment templates.
A conditinal is used in puppet/role.role.j2.yaml so that
the parameter value is used whenever it is not '' (the
default) to provide backwards compatibility in case the
user set a different value for this parameter in
network-environment.yaml.
When deploying a routed control plane the network config
templates would previously need to be updated to carry
'EC2MetadatIpLeafX' parameters for each leaf. By getting
the value to pass from the server resource this change
reduces the required nic-config template customisation.
(Reduces the risk of user error.)
Partial: blueprint tripleo-routed-networks-templates
Change-Id: I9c019ec840a44ca8c5f98be55daea365bc6554ec
Use get_attr on the server resource to resolve attribute
value from the subnet(s) and pass it to the parameter
'ControlPlaneDefaultRoute' used in the THT/network/config/*
templates.
Changes the default for 'ControlPlaneDefaultRoute' to ''
as well as the comment that the value should be overriden
in parameters_defaults. It also removes the parameter from
network-environment templates.
A conditinal is used in puppet/role.role.j2.yaml so that
the parameter value is used whenever it is not '' (the
default) to provide backwards compatibility in case the
user set a different value (different from the one used in
undercloud.conf) for this parameter in
network-environment.yaml.
When deploying a routed control plane the network config
templates would previously need to be updated to carry
'ControlPlaneXDefaultRoute' parameters for each leaf. With
8 Leafs in addition to the network local to the undercloud
that is 8 parameters less to place in the configuration.
By getting the value to pass from the server resource this
change reduces the required nic-config template
customisation (reduces the risk of user error).
Partial: blueprint tripleo-routed-networks-templates
Change-Id: I5139249d55e9ac01761c270b8c0f31ef35595940
Use get_attr on the server resource to resolve attribute
value from the subnet(s) and pass it to the parameter
'ControlPlaneSubnetCidr' used in the THT/network/config/*
templates.
As the value is now resolved from resource attributes,
this changes the default for 'ControlPlaneSubnetCidr' to ''
as well as the comment that these value should be overriden
in parameters_defaults. It also removes the parameter from
network-environment templates.
A conditinal is used in puppet/role.role.j2.yaml so that
the parameter value is used whenever it is not '' (the
default) to provide backwards compatibility in case the user
set a different value (different from the one used in
undercloud.conf) for this parameter in
network-environment.yaml.
When deploying a routed control plane the network config
templates would previously need to be updated to carry
'ControlPlaneXSubnetCidr' parameter (in case the subnet
mask is not the same for all the routed network leafs).
With 8 Leafs in addition to the network local to the
undercloud that is 8 parameters less to place in the
configuration. By getting the value to pass from the
server resource this change reduces the required nic-config
template customisation (reduces the risk of user error).
Partial: blueprint tripleo-routed-networks-templates
Change-Id: I92ee0f9a2107cdf1ca5903d3756a235a79c36c73
For a standalone all-in-one, we need to create a basic role that has
some of the services, a network config for a single node and an
environment file that has all the services defined but disabled so
that we can enable just the services we will need. In the future, we
will likely make the service list more dynamic but for now it contains a
minimal set of services for a keystone/openshift/kubernetes deployment.
Change-Id: Ieb7c94563bd0132393b5fa268d743981f6e0b6f2
Related-Blueprint: all-in-one