When using neutron routed networks we need to specify
either the subnet or a ip address in the fixed-ips-request
when creating neutron ports.
a) For the Vip's:
Adds VipSubnetMap and VipSubnetMapDefaults parameters in
service_net_map.yaml. The two maps are merged, so that the
operator can override the subnet where VIP port should be
hosted. For example:
parameter_defaults:
VipSubnetMap:
ctlplane: ctlplane-leaf1
InternalApi: internal_api_leaf1
Storage: storage_leaf1
redis: internal_api_leaf1
b) For overcloud node ports:
Enrich 'networks' in roles defenition to include both
network and subnet data. Changes the list to a map
instead of a list of strings. New schema:
- name: <role_name>
networks:
<network_name>
subnet: <subnet_name>
For backward compatibility a conditional is used to check
if the data is a map or not. In either case the internal
list of role networks is created as '_role_networks' in
the jinja2 templates.
When the data is a map, and the map contains the 'subnet'
key the subnet specified in roles_data.yaml is used as
the subnet in the fixed-ips-reqest when ports are created.
If subnet is not set (or role.networks is not a map) the
default will be {{network.name_lower}}_subnet.
Also, since the fixed_ips request passed to Vip ports are no
longer [] by default, the conditinal has been updated to
test for 'ip_address' entries in the request.
Partial: blueprint tripleo-routed-networks-templates
Depends-On: I773a38fd903fe287132151a4d178326a46890969
Change-Id: I77edc82723d00bfece6752b5dd2c79137db93443
Add parameters for the subnets of each network in network_data
yaml. Associates the base subnet of each network with the first
segment of the network. (All networks have an implicit first
network segment when they are created.)
Additional segments and subnets defined in the ``subnets`` key
of each composable network is created with subnet to segment
association.
Partial: blueprint tripleo-routed-networks-templates
Change-Id: I53559ed1445f66fa50508ac9898cbec07914b3fc
This will be the parameter controlling the ports
for the Keystone WSGI vhost in Apache when this [1]
rework is done.
This is to make sure Keystone is still deployed
with both ports in TripleO until it's moved over.
[1] https://review.openstack.org/#/c/619257/
Change-Id: I1c69b27adf450489290a9f8b64f533de1cb28d8b
Change: I11e38f82eb9040f77412fe8ad200fcc48031e2f8 introduced mtu
property for composable networks. This change set the MTU of the
Tenant network as the global_physnet_mtu for neutron, unless the
NeutronGlobalPhysnetMtu is overridden. The default MTU used if
no MTU is defined for the Tenant network is 1500. (The same
default was previously used for the NeutronGlobalPhysnetMtu
parameter.)
Change-Id: I5e60d52ad571e1cdb3b82cd1d9947e33fa682bf8
Change: I4ba148f465b4c452bd5b2c31009ac8a2897bcd5f makes
dhcp_start and dhcp_end optional for non-local subnet
definitions in undercloud.conf.
Start using the AllocationPools parameter istead of the
legacy DhcpStart | DhcpEnd parameters.
Closes-Bug: #1806512
Closes-Bug: #1807707
Depends-On: I4ba148f465b4c452bd5b2c31009ac8a2897bcd5f
Change-Id: Ifdf3e9d22766c1b5ede151979b93754a3d244cc3
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
Following addition of [1], replace use of multinode with
standalone job for scenario004
1. https://review.openstack.org/#/c/619520/
Change-Id: Iff1e83dd227fc2e03924f41592f82a555053425d
Adds support for the Thales and ATOS client software.
Change-Id: I79f8608431fecc58c8bdeba2de4a692a7ee388e9
Co-Authored-By: Douglas Mendizabal <dmendiza@redhat.com>
Neutron services failing with below Error when running
with podman(0.12.1) and container-selinux(2.77):-
relabel failed "/run/netns": operation not supported
Until this is fixed in podman/container-selinux, temporary
remove selinux relabel on /run/netns.
Depends-On: https://review.openstack.org/#/c/626546/
Change-Id: Iedbeac17a0c530ecdc7e8cbba5ddd4ffb22bb616
Partial-Bug: #1809218
As of now, during to upgrade from pike -> queens or doing
minor update on pike/queens deployment, the nova packages upgrade
on compute node changes the permissions on /var/lib/nova tree from
42436 (container nova uid) to 162 (host nova uid) which
prevents user from creating instances with permission Error.
This change handles removing unused nova packages from compute
host during major upgrade as well as minor update on explicitly.
Change-Id: I7e7167252f08f5df555912e0692f33649228fc83