Support for deploying neutron-lbaas was removed in the Train release. We
no longer need the task to remove the container in the upgrade process.
Change-Id: Ie336f68c710616de29f34dd4011e137ec056973b
The version_compare filter was renamed to version and changed to be a
test in 2.5. The old filter was removed in 2.9.
TrivialFix
Change-Id: Ib5d91b5fc53d0f6d16dd6eb38121cd9914e33d93
See https://bugs.launchpad.net/oslo.rootwrap/+bug/1760471, in particular
comment #1 for an explanation of why inheriting the defaults of the
docker daemon can cause poor performance:
The performance difference likely comes from close_fds=True of subprocess.
Popen. On Python 2, Popen calls close(fd) on all file descriptors from 3 to
SC_OPEN_MAX. On my Fedora 27 "host", SC_OPEN_MAX is 1,024. But in docker,
SC_OPEN_MAX is... 1,048,576: 1,000x larger. On Python 3, Popen is smarter. On
Linux, it lists the content of /proc/self/fd/ to only close open file
descriptors. It doesn't depend on SC_OPEN_MAX value.
Change-Id: Iefef6039644192420abbd3bf614329cbc0d9a62a
Closes-Bug: #1848737
Related-Bug: #1760471
Related-Bug: #1757556
Related-Bug: #1824020
neutron_legacy_iptables option sets the KOLLA_LEGACY_IPTABLES
environment variable in the neutron-l3-agent, neutron-linuxbridge-agent
and neutron_openvswich_agent container where it should be consumed
by kolla_extended_start script resulting in setting iptables-legacy.
Depends-On: https://review.opendev.org/#/c/683679/
Change-Id: Iaa8b46a2227b61a729b8d54bbe4b20f389f251d1
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>
The deprecated ovsdb_interface configuration option has been removed,
the default native driver is now always used. [1]
[1] cf37563c83
Change-Id: Idd4e8ad4b00064d180a50c7b98a4568804939f50
Signed-off-by: ZijianGuo <guozijn@gmail.com>
Sometimes as cloud admins, we want to only update code that is running
in a cloud. But we dont need to do anything else. Make an action in
kolla-ansible that allows us to do that.
Change-Id: I904f595c69f7276e71692696471e32fd1f88e6e8
Implements: blueprint deploy-containers-action
Use upstream Ansible modules for registration of services, endpoints,
users, projects, roles, and role grants.
Change-Id: I7c9138d422cc91c177fd8992347176bb54156b5a
Allows enabling neutron port forwarding plugin
and l3 extension to forward ports from floating
IP to a fixed neutron port.
Change-Id: Ic25c96a0ddcf4f69acbfb7a58acafec82c3b0aed
Implements: blueprint enable-l3-port-forwarding
This commit adds the functionality for an operator to specify
their own trusted CA certificate file for interacting with the
Keystone API.
Implements: blueprint support-trusted-ca-certificate-file
Change-Id: I84f9897cc8e107658701fb309ec318c0f805883b
Because we merged both [1] and [2] in master,
we got broken FWaaS.
This patch unbreaks it and is required to backport
to Stein due to [2] backport waiting for merge,
while [1] is already backported.
[1] https://review.opendev.org/661704
[2] https://review.opendev.org/668406
Change-Id: I74427ce9b937c42393d86574614603bd788606af
Signed-off-by: Radosław Piliszek <radoslaw.piliszek@gmail.com>
In the Stein release, neutron-dynamic-routing switched from
using ryu to os-ken (a fork of ryu). The config option
bgp_speaker_driver [1] is currently set in kolla-ansible to use the ryu
driver, but this is not included in the image due to it being removed
from neutron-dynamic-routing's requirements.txt.
This change uses the os-ken driver for bgp_speaker_driver, since this
package is included in the image.
[1] https://docs.openstack.org/neutron-dynamic-routing/latest/contributor/dragent-drivers.html#bgp-driver
Change-Id: I76ad84c6b963818208f080ebeb054b2553ff40af
Closes-Bug: #1839165
According to Docker upstream release notes [1] MountFlags should be
empty.
1. https://docs.docker.com/engine/release-notes/#18091
"Important notes about this release
In Docker versions prior to 18.09, containerd was managed by the Docker
engine daemon. In Docker Engine 18.09, containerd is managed by systemd.
Since containerd is managed by systemd, any custom configuration to the
docker.service systemd configuration which changes mount settings (for
example, MountFlags=slave) breaks interactions between the Docker Engine
daemon and containerd, and you will not be able to start containers.
Run the following command to get the current value of the MountFlags
property for the docker.service:
sudo systemctl show --property=MountFlags docker.service
MountFlags=
Update your configuration if this command prints a non-empty value for
MountFlags, and restart the docker service."
Closes-bug: #1833835
Change-Id: I4f4cbb09df752d00073a606463c62f0a6ca6c067
Neutron FWaaS v1 is deprecated and removed since stein cycle by [0]. So
remove related options in kolla.
[0] https://review.opendev.org/616410
Change-Id: Ia03e7979dd48bafb34c11edd08c2a2a87b949e0e
Docker has no restart policy named 'never'. It has 'no'.
This has bitten us already (see [1]) and might bite us again whenever
we want to change the restart policy to 'no'.
This patch makes our docker integration honor all valid restart policies
and only valid restart policies.
All relevant docker restart policy usages are patched as well.
I added some FIXMEs around which are relevant to kolla-ansible docker
integration. They are not fixed in here to not alter behavior.
[1] https://review.opendev.org/667363
Change-Id: I1c9764fb9bbda08a71186091aced67433ad4e3d6
Signed-off-by: Radosław Piliszek <radoslaw.piliszek@gmail.com>
A common class of problems goes like this:
* kolla-ansible deploy
* Hit a problem, often in ansible/roles/*/tasks/bootstrap.yml
* Re-run kolla-ansible deploy
* Service fails to start
This happens because the DB is created during the first run, but for some
reason we fail before performing the DB sync. This means that on the second run
we don't include ansible/roles/*/tasks/bootstrap_service.yml because the DB
already exists, and therefore still don't perform the DB sync. However this
time, the command may complete without apparent error.
We should be less careful about when we perform the DB sync, and do it whenever
it is necessary. There is an argument for not doing the sync during a
'reconfigure' command, although we will not change that here.
This change only always performs the DB sync during 'deploy' and
'reconfigure' commands.
Change-Id: I82d30f3fcf325a3fdff3c59f19a1f88055b566cc
Closes-Bug: #1823766
Closes-Bug: #1797814
Currently, we have a lot of logic for checking if a handler should run,
depending on whether config files have changed and whether the
container configuration has changed. As rm_work pointed out during
the recent haproxy refactor, these conditionals are typically
unnecessary - we can rely on Ansible's handler notification system
to only trigger handlers when they need to run. This removes a lot
of error prone code.
This patch removes conditional handler logic for all services. It is
important to ensure that we no longer trigger handlers when unnecessary,
because without these checks in place it will trigger a restart of the
containers.
Implements: blueprint simplify-handlers
Change-Id: I4f1aa03e9a9faaf8aecd556dfeafdb834042e4cd
The project has been retired and there will be no Train release [1].
This patch removes Neutron LBaaS support in Kolla.
[1] https://review.opendev.org/#/c/658494/
Change-Id: Ic0d3da02b9556a34d8c27ca21a1ebb3af1f5d34c
Many tasks that use Docker have become specified already, but
not all. This change ensures all tasks that use the following
modules have become:
* kolla_docker
* kolla_ceph_keyring
* kolla_toolbox
* kolla_container_facts
It also adds become for 'command' tasks that use docker CLI.
Change-Id: I4a5ebcedaccb9261dbc958ec67e8077d7980e496
As described in document [1], the service_provider should be set to
'FIREWALL_V2:fwaas_db:neutron_fwaas.services.firewall.service_drivers.
agents.agents.FirewallAgentDriver:default' for FWaaS v2.
[1] https://docs.openstack.org/neutron/stein/admin/fwaas-v2-scenario.html#enable-fwaas-v2
Change-Id: Iad3e906af325ba3209a77a91ab2061e515b4a219
Signed-off-by: ZijianGuo <guozijn@gmail.com>
When integrating 3rd party component into openstack with kolla-ansible,
maybe have to mount some extra volumes to container.
Change-Id: I69108209320edad4c4ffa37dabadff62d7340939
Implements: blueprint support-extra-volumes
Since Ansible 2.5, the use of jinja tests as filters has been
deprecated.
I've run the script provided by the ansible team to 'fix' the
jinja filters to conform to the newer syntax.
This fixes the deprecation warnings.
Change-Id: I844ecb7bec94e561afb09580f58b1bf83a6d00bd
Closes-bug: #1827370
Add a possibility to mount sources as volumes to containers,
in "more than documentation" way. That will let us to use kolla
as a replacement for devstack.
Partially implements: blueprint mount-sources
Change-Id: I4868ed6829bd037e1012d1f40c4a1d1b9995bf95
Several config file permissions are incorrect on the host. In general,
files should be 0660, and directories and executables 0770.
Change-Id: Id276ac1864f280554e98b937f2845bb424d521de
Closes-Bug: #1821579
Services were being passed as a JSON list, then iterated over in the
neutron-server container's extend_start.sh script like this:
['neutron-server'
'neutron-fwaas'
'neutron-vpnaas']
I'm not actually sure why we have to specify services explicitly, it
seems liable to break if we have other plugins that need migrating.
Change-Id: Ic8ce595793cbe0772e44c041246d5af3a9471d44
When adding the rolling upgrade support, some upgrade procedures were
modified to pull images explicitly. This is done inconsistently between
services, and is a change in behaviour from Rocky and earlier releases.
This change removes all image pulling from upgrade tasks.
Change-Id: Id0fed17714235e1daed60b83b1f30620f097eb97
With newer Docker versions `systemctl show docker` returns:
MountFlags=shared
Instead of:
MountFlags=1048576
This fix accepts either value as valid to ensure the check is not
erroneously failing.
Closes-Bug: #1791365
Change-Id: I2bd626466d6a0e189e0d85877b2be8f2b4bb37f4
This allows octavia service endpoints to use custom hostnames, and adds the
following variables:
* octavia_internal_fqdn
* octavia_external_fqdn
These default to the old values of kolla_internal_fqdn or
kolla_external_fqdn.
This also adds a octavia_api_listen_port option, which defaults to
octavia_api_port for backward compatibility.
This option allow the user to differentiate between the port the
service listens on, and the port the service is reachable on. This is
useful for external load balancers which live on the same host as the
service itself.
Change-Id: I1310eb5573a469b1a0e9549e853734455307a8b3
Implements: blueprint service-hostnames
This allows designate service endpoints to use custom hostnames, and adds
the
following variables:
* designate_internal_fqdn
* designate_external_fqdn
These default to the old values of kolla_internal_fqdn or
kolla_external_fqdn.
This also adds a designate_api_listen_port option, which defaults to
designate_api_port for backward compatibility.
This option allow the user to differentiate between the port the
service listens on, and the port the service is reachable on. This is
useful for external load balancers which live on the same host as the
service itself.
Change-Id: I654bb3d1109b96cbaff6f450655cd65f349a94e6
Implements: blueprint service-hostnames
We're duplicating code to build the keystone URLs in nearly every
config, where we've already done it in group_vars. Replace the
redundancy with a variable that does the same thing.
Change-Id: I207d77870e2535c1cdcbc5eaf704f0448ac85a7a
This allows neutron service endpoints to use custom hostnames, and adds the
following variables:
* neutron_internal_fqdn
* neutron_external_fqdn
These default to the old values of kolla_internal_fqdn or
kolla_external_fqdn.
This also adds a neutron_server_listen_port option, which defaults to
neutron_server_port for backward compatibility.
This option allow the user to differentiate between the port the
service listens on, and the port the service is reachable on. This is
useful for external load balancers which live on the same host as the
service itself.
Change-Id: I87d7387326b6eaa6adae1600b48d480319d10676
Implements: blueprint service-hostnames
This allows nova service endpoints to use custom hostnames, and adds the
following variables:
* nova_internal_fqdn
* nova_external_fqdn
* placement_internal_fqdn
* placement_external_fqdn
* nova_novncproxy_fqdn
* nova_spicehtml5proxy_fqdn
* nova_serialproxy_fqdn
These default to the old values of kolla_internal_fqdn or
kolla_external_fqdn.
This also adds the following variables:
* nova_api_listen_port
* nova_metadata_listen_port
* nova_novncproxy_listen_port
* nova_spicehtml5proxy_listen_port
* nova_serialproxy_listen_port
* placement_api_listen_port
These default to <service>_port, e.g. nova_api_port, for backward
compatibility.
These options allow the user to differentiate between the port the
service listens on, and the port the service is reachable on. This is
useful for external load balancers which live on the same host as the
service itself.
Change-Id: I7bcce56a2138eeadcabac79dd07c8dba1c5af644
Implements: blueprint service-hostnames
The neutron containers were not being restarted if only the ml2_conf.ini
file is changed. This is due to the XenAPI ml2_conf.ini config task
registering a variable of the same name as the task that generates
ml2_conf.ini for other services. Since the XenAPI service is typically
not running, the tasks show as not changed, and the handler skips
restarting the container.
This change adds a second variable for XenAPI to avoid this shadowing.
Change-Id: I77819ed8defb8a7653e1e5aec92013b1d40fbf02
Closes-Bug: #1783268
According [1], vitrage notification has to be configured in Nova,
Neutron, Cinder & Aodh config file.
[1] https://review.openstack.org/#/c/302802/
Change-Id: Iaf8cd7d40e6eb988adf4d208e6ad784f1004caa5
