This page documents some of the common configurations that can be enabled
through ansible variables. The ansible variables that affect the configuration
of the ansible executions are set in the ansibleVars field on the dataplane
resources.
The full set of ansible variables available for configuration are documented within each role in the edpm-ansible repository.
Variable: edpm_bootstrap_command
Type: string
Role: edpm_bootstrap
The edpm_bootstrap_command variable can be used to pass a shell command(s) that
will be executed as early as possible in the deployment as part of the
configure-network service. If the services list is customized with services
that execute prior to configure-network then the command(s) specified by
edpm_bootstrap_command would run after the custom services.
The string value for edpm_bootstrap_command is passed directly to the ansible
shell.
As such, when using multiple shell commands, the | character must be used to
preserve new lines in the YAML value:
edpm_bootstrap_command: |
command 1
command 2
etc.
edpm_bootstrap_command can be used to perform system registration in order to
enable needed package repositories. Choose a registration method (either Portal
or Satellite) and refer to the provided links below for instructions to create
the registration commands.
The registration commands for the Red Hat Customer Portal are documented at https://access.redhat.com/solutions/253273.
The registration commands for Red Hat Satellite version 6.13 are documented at https://access.redhat.com/documentation/en-us/red_hat_satellite/6.13/html-single/managing_hosts/index#Registering_Hosts_to_Server_managing-hosts.
If not using Satellite version 6.13, then refer to the specific version of the documentation for the version of Satellite that is in use.
edpm_bootstrap_command can be used to configure system proxy settings by
adding the proxy environment variables to /etc/environment.
edpm_bootstrap_command: |
cat >>/etc/environment <<EOF
http_proxy="http://USERNAME:PASSWORD@proxy-server.example.com:3128/"
https_proxy="http://USERNAME:PASSWORD@proxy-server.example.com:3128/"
no_proxy="localhost,127.0.0.1,::1" # Add any hosts to bypass the proxy
EOF
Note that these variable values won’t always apply to tasks executed by
ansible. To ensure ansible tasks always use a proxy, create the
edpm_playbook_environment secret and reference it on the
OpenStackDataPlaneNodeSet as shown in
xref:proc_creating-a-set-of-data-plane-nodes.adoc.
The container images used by the various roles from edpm-ansible can pull from customized locations. The ansible variables used to set the locations and their default values are:
edpm_iscsid_image: "quay.io/podified-antelope-centos9/openstack-iscsid edpm_logrotate_crond_image: "quay.io/podified-antelope-centos9/openstack-cron edpm_ovn_controller_agent_image: "quay.io/podified-antelope-centos9/openstack-ovn-controller edpm_frr_image: "quay.io/podified-antelope-centos9/openstack-frr edpm_ovn_bgp_agent_image: "quay.io/podified-antelope-centos9/openstack-ovn-bgp-agent edpm_ovn_bgp_agent_local_ovn_nb_db_image: "quay.io/podified-antelope-centos9/openstack-ovn-nb-db-server edpm_ovn_bgp_agent_local_ovn_sb_db_image: "quay.io/podified-antelope-centos9/openstack-ovn-sb-db-server edpm_ovn_bgp_agent_local_ovn_northd_image: "quay.io/podified-antelope-centos9/openstack-ovn-northd edpm_ovn_bgp_agent_local_ovn_controller_image: "quay.io/podified-antelope-centos9/openstack-ovn-controller edpm_telemetry_node_exporter_image: quay.io/prometheus/node-exporter edpm_telemetry_kepler_image: "quay.io/sustainable_computing_io/kepler" edpm_telemetry_ceilometer_compute_image: quay.io/podified-antelope-centos9/openstack-ceilometer-compute edpm_telemetry_ceilometer_ipmi_image: quay.io/podified-antelope-centos9/openstack-ceilometer-ipmi edpm_nova_compute_image: "quay.io/podified-antelope-centos9/openstack-nova-compute edpm_neutron_sriov_image: "quay.io/podified-antelope-centos9/openstack-neutron-sriov-agent edpm_multipathd_image: "quay.io/podified-antelope-centos9/openstack-multipathd edpm_neutron_dhcp_image: "quay.io/podified-antelope-centos9/openstack-neutron-dhcp-agent edpm_neutron_metadata_agent_image: "quay.io/podified-antelope-centos9/openstack-neutron-metadata-agent-ovn edpm_neutron_ovn_agent_image: "quay.io/podified-antelope-centos9/openstack-neutron-ovn-agent edpm_swift_proxy_image: "quay.io/podified-antelope-centos9/openstack-swift-proxy-server edpm_swift_account_image: "quay.io/podified-antelope-centos9/openstack-swift-account edpm_swift_container_image: "quay.io/podified-antelope-centos9/openstack-swift-container edpm_swift_object_image: "quay.io/podified-antelope-centos9/openstack-swift-object
Set any of the above ansible variables within the ansibleVars sections of
OpenStackDataPlaneNodeSet to customize the container image locations.
Network Isolation refers to the practice of separating network traffic by function, and configuring the networks on dataplane nodes. Nodes will need connectivity to various control plane services running on OCP. These services may be bound to different networks. Each of those networks needs to be configured as required on dataplane nodes.
For further details on the network architecture of the control plane, see https://github.com/openstack-k8s-operators/docs/blob/main/networking.md.
The edpm_network_config ansible role is responsible for configuring networking on dataplane nodes.
The edpm_network_config_template variable specifies the contents of a jinja2
template that describes the networking configuration to be applied. The
template itself also contains variables that can be used to customize the
networking configuration for a specific node (IP addresses, interface names,
routes, etc). See template examples provided in the nic-config-samples directory:
https://github.com/openstack-k8s-operators/openstack-operator/tree/main/config/samples/nic-config-samples.
These samples can be used inline within the OpenStackDataPlaneNodeSet CR
under then ansibleVars section (see our current sample files for examples
of the inline implementation).
The following is an example
ansibleVars
field that shows defining the variables that configure the
edpm_network_config role.
ansibleVars:
ctlplane_ip: 192.168.122.100
internalapi_ip: 172.17.0.100
storage_ip: 172.18.0.100
tenant_ip: 172.19.0.100
fqdn_internalapi: edpm-compute-0.example.com
edpm_network_config_template: |
---
{% set mtu_list = [ctlplane_mtu] %}
{% for network in nodeset_networks %}
{% set _ = mtu_list.append(lookup('vars', networks_lower[network] ~ '_mtu')) %}
{%- endfor %}
{% set min_viable_mtu = mtu_list | max %}
network_config:
- type: ovs_bridge
name: {{ neutron_physical_bridge_name }}
mtu: {{ min_viable_mtu }}
use_dhcp: false
dns_servers: {{ ctlplane_dns_nameservers }}
domain: {{ dns_search_domains }}
addresses:
- ip_netmask: {{ ctlplane_ip }}/{{ ctlplane_cidr }}
routes: {{ ctlplane_host_routes }}
members:
- type: interface
name: nic1
mtu: {{ min_viable_mtu }}
# force the MAC address of the bridge to this interface
primary: true
{% for network in nodeset_networks %}
- type: vlan
mtu: {{ lookup('vars', networks_lower[network] ~ '_mtu') }}
vlan_id: {{ lookup('vars', networks_lower[network] ~ '_vlan_id') }}
addresses:
- ip_netmask:
{{ lookup('vars', networks_lower[network] ~ '_ip') }}/{{ lookup('vars', networks_lower[network] ~ '_cidr') }}
routes: {{ lookup('vars', networks_lower[network] ~ '_host_routes') }}
{% endfor %}
This configuration would be applied by the configure-network service when it’s executed.
The
NetworkAttachmentDefinition
resource is used to describe how pods can be attached to different networks.
Network attachment definitions can be specified on the
OpenStackDataPlaneNodeSet resource using the
NetworkAttachments field.
The network attachments are used to describe which networks will be connected
to the pod that is running ansible-runner. They do not enable networks on the
dataplane nodes themselves. For example, adding the internalapi network
attachment to NetworkAttachments means the ansible-runner pod will be
connected to the internalapi network. This can enable scenarios where ansible
needs to connect to different networks.