Previously, if a user provided a custom neutron ML2 configuration file in
/home/stackhpc-mark/kayobe/src/kayobe-config/etc/kayobe/neutron/ml2_conf.ini, it would overwrite the options set by
kayobe. This change applies the 'ignore' rule when copying custom config files,
as well as when deleting them. This works because we read in the contents of
these files and append it to kayobe's own configuration.
Supports removal of custom config files in $KAYOBE_CONFIG_PATH/kolla/config/, and
adds support for ironic, keystone, magnum, murano, sahara, and swift custom config.
Allows kolla_neutron_ml2_generic_switch_extra to define a dict of additional
config options to add to per-switch configuration for the neutron ML2 generic
switch driver. These options may be switch host-specific.
Previously a URL based on the provisioning network IP was being advertised to
nodes during provisioning. The issue here is that the API server might not be
listening on the provisioning network. Instead we advertise the internal network
endpoint and assume that if any routes are required to enable this then they
have been created elsewhere.
In environments without Swift we are currently unable to store hardware
introspection data. The inspection_store container runs an nginx server
that supports a restricted Swift-like HTTP API using WebDAV that supports
upload and retrieval of introspection data.
Overcloud deployment images can now be built via:
kayobe overcloud deployment image build
This should be done prior to running kayobe overcloud service deploy.
In order to build IPA images, the ipa_build_images variable should be
set to True. In this case, these images will be used by the overcloud's
ironic inspector service during hardware inspection, and by ironic
during provisioning.
We use the switch interface configuration to provide a list of interfaces
to the neutron ML2 generic switch driver to be configured as trunk ports
in each neutron network. These interfaces correspond to the controllers
by default, which need access to all of the networks in order to provide
services such as DHCP and routing.
Related-Bug: #1690115
For VLAN networks we need to use a tagged Linux bridge on the controller with a
veth pair to link it to the corresponding Neutron OVS bridge. This must be done
for the physical network(s) carrying the provisioning, tenant, and external
network traffic. We also need untagged VLAN subinterfaces on the tagged bridge
for the controller to communicate on these networks with.
The network interface role in use requires that we use two passes through
interface configuration to ensure that VLAN subinterfaces can be added to
bridge interfaces.
Finally, we must configure Ironic with the name of the Neutron network used
for provisioning.