| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
kolla_address does not check if the returned ip address is a loopback
for ipv4 addresses, this change checks, and always try to return the
first non loopback address, defaulting to the primary in case only
loopbacks are available.
Closes-Bug: #2085699
Change-Id: Ie8a8b6156e6db025aba94e80a4b3aa2bf72d73ef
Signed-off-by: Bertrand Lanson <bertrand.lanson@protonmail.com>
|
|
In many cases we use the kolla_address filter to look up the IP address
of the current host or another host on a particular network interface.
This filter uses the host's facts to determine the IP, meaning that we
must have gathered facts for the host, even if it is outside of a
requested --limit. This is a limitation, since it requires that all
hosts must be reachable, even if we are not directly configuring them.
Most instances of this cross-host fact referencing involve a controller,
since they host clustered services. The only instance found to affect
compute nodes is in the prometheus role, where Prometheus server needs
to know the IP address of all targets in its scrape configs.
If we are able to specify the address of the scrape targets as a static
variable such as a host variable, then facts would not be required for
compute nodes outside of the --limit.
Removing the requirement to have facts for all compute nodes has
benefits for performance (gathering facts for all hosts can take a long
time) and fault tolerance (we can operate when some compute hosts are
unreachable).
This change modifies the kolla_address filter to accept an optional
override_var argument which can be used to specify the name of a host
variable that may override the returned IP address. This is used in the
Prometheus server configuration to allow specifying the IP address used
by Prometheus server when collecting metrics from exporter using
a 'prometheus_target_address' host variable. If specified, this takes
precedence over the API interface address currently used. This makes it
possible to statically override prometheus_target_address and avoid the
cross-host fact reference.
This is not a complete solution because it is not yet possible to skip
the cross-host fact gathering step.
Partial-Bug: #2041860
Change-Id: I207ca56362de00d8ec578333eab9e1a72e7bcd19
|
|
Unlike other methods such as resolve(), get() does not return an Undefined object, but None.
This removes 4 ansible-lint warnings in various files calling kolla_address.
Closes-Bug: #2038281
Change-Id: I591a50512a954210f951c40a350ed4b9e1fc48ae
|
|
The contextfilter decorator was deprecated in jinja2 3.0.0, and has been
dropped in 3.1.0. This results in the following warning, and failed
attempts to use filters:
[WARNING]: Skipping plugin (filters.py) as it seems to be invalid:
module 'jinja2' has no attribute 'contextfilter'
This change switches to use the pass_context decorator. The minimum
version of Jinja2 is raised to 3 to ensure pass_context is present.
Change-Id: I649dd6211d3ae72b9539bc44652ef8cf5d579777
|
|
By default, Ansible injects a variable for every fact, prefixed with
ansible_. This can result in a large number of variables for each host,
which at scale can incur a performance penalty. Ansible provides a
configuration option [0] that can be set to False to prevent this
injection of facts. In this case, facts should be referenced via
ansible_facts.<fact>.
This change updates all references to Ansible facts within Kolla Ansible
from using individual fact variables to using the items in the
ansible_facts dictionary. This allows users to disable fact variable
injection in their Ansible configuration, which may provide some
performance improvement.
This change disables fact variable injection in the ansible
configuration used in CI, to catch any attempts to use the injected
variables.
[0] https://docs.ansible.com/ansible/latest/reference_appendices/config.html#inject-facts-as-vars
Change-Id: I7e9d5c9b8b9164d4aee3abb4e37c8f28d98ff5d1
Partially-Implements: blueprint performance-improvements
|
|
This includes some lightweight refactoring to avoid code
duplication.
This patch is made to be backportable to Train.
We now include Ansible in testing since Ussuri so the comments
about the bool filter are wrong.
Change-Id: Ia2e0f7f24988763bacfeafefb7977021f5949f4e
Closes-bug: #1848941
|
|
Introduce kolla_address filter.
Introduce put_address_in_context filter.
Add AF config to vars.
Address contexts:
- raw (default): <ADDR>
- memcache: inet6:[<ADDR>]
- url: [<ADDR>]
Other changes:
globals.yml - mention just IP in comment
prechecks/port_checks (api_intf) - kolla_address handles validation
3x interface conditional (swift configs: replication/storage)
2x interface variable definition with hostname
(haproxy listens; api intf)
1x interface variable definition with hostname with bifrost exclusion
(baremetal pre-install /etc/hosts; api intf)
neutron's ml2 'overlay_ip_version' set to 6 for IPv6 on tunnel network
basic multinode source CI job for IPv6
prechecks for rabbitmq and qdrouterd use proper NSS database now
MariaDB Galera Cluster WSREP SST mariabackup workaround
(socat and IPv6)
Ceph naming workaround in CI
TODO: probably needs documenting
RabbitMQ IPv6-only proto_dist
Ceph ms switch to IPv6 mode
Remove neutron-server ml2_type_vxlan/vxlan_group setting
as it is not used (let's avoid any confusion)
and could break setups without proper multicast routing
if it started working (also IPv4-only)
haproxy upgrade checks for slaves based on ipv6 addresses
TODO:
ovs-dpdk grabs ipv4 network address (w/ prefix len / submask)
not supported, invalid by default because neutron_external has no address
No idea whether ovs-dpdk works at all atm.
ml2 for xenapi
Xen is not supported too well.
This would require working with XenAPI facts.
rp_filter setting
This would require meddling with ip6tables (there is no sysctl param).
By default nothing is dropped.
Unlikely we really need it.
ironic dnsmasq is configured IPv4-only
dnsmasq needs DHCPv6 options and testing in vivo.
KNOWN ISSUES (beyond us):
One cannot use IPv6 address to reference the image for docker like we
currently do, see: https://github.com/moby/moby/issues/39033
(docker_registry; docker API 400 - invalid reference format)
workaround: use hostname/FQDN
RabbitMQ may fail to bind to IPv6 if hostname resolves also to IPv4.
This is due to old RabbitMQ versions available in images.
IPv4 is preferred by default and may fail in the IPv6-only scenario.
This should be no problem in real life as IPv6-only is indeed IPv6-only.
Also, when new RabbitMQ (3.7.16/3.8+) makes it into images, this will
no longer be relevant as we supply all the necessary config.
See: https://github.com/rabbitmq/rabbitmq-server/pull/1982
For reliable runs, at least Ansible 2.8 is required (2.8.5 confirmed
to work well). Older Ansible versions are known to miss IPv6 addresses
in interface facts. This may affect redeploys, reconfigures and
upgrades which run after VIP address is assigned.
See: https://github.com/ansible/ansible/issues/63227
Bifrost Train does not support IPv6 deployments.
See: https://storyboard.openstack.org/#!/story/2006689
Change-Id: Ia34e6916ea4f99e9522cd2ddde03a0a4776f7e2c
Implements: blueprint ipv6-control-plane
Signed-off-by: Radosław Piliszek <radoslaw.piliszek@gmail.com>
|
