In order to reduce divergance with ansible-lint rules, we apply
auto-fixing of violations.
In current patch we replace all kind of truthy variables with
`true` or `false` values to align with recommendations along with
alignment of used quotes.
Change-Id: Ibcbb660f39c067e68b699436ef2da0903c8500fd
During revert of the change Id38a671ff8b5535f232c09a8365963f613eb5bc8 it
was also accidentally reverted introduction of services which
were required for uWSGI mode.
Without these services being defined, they will not be stopped/managed
while disabling uWSGI on upgrade.
Change-Id: I21302b2cccea794fdf567056eee52ac073aadfb2
There is no reason to evaluate groups condition multiple times,
as we are not placing OVN TLS configuration without more basic
config anyway. So condition evaluation can be simplified and made
more readable.
Change-Id: If33870c00cc139e0fc8de4ec69adf331f178ee9d
At the moment variable neutron_dnsmasq_dns_servers is respected
only for OVS/LXB scenarios, when dnsmasq is used. At the same
time we do not have any sane way to supply a list of DNS servers
for OVN.
Let's re-use the variable as actual behaviour behind it will be the
same [1]
[1] https://docs.openstack.org/neutron/latest/configuration/ml2-conf.html#ovn.dns_servers
Change-Id: Iabe6381fe9add1b3fac4179fdcd3d49dab099dad
This reverts commit 48a935d7c8a8a96d6e66f0cc1b4b7fb7b33760bb.
Reason for revert: A bug was reported regarding uWSGI issue with multinode
setup
Change-Id: Id38a671ff8b5535f232c09a8365963f613eb5bc8
Closes-Bug: #2096937
Without an explicit interface set, keystoneauth appears to default
to public. Internal seems like a more sensible default.
This can be overridden via neutron_ironic_neutron_agent_ini_overrides
Change-Id: Ia1f09d5d45fe073936214ffb141fcddbc5eebe4a
In case QoS is enabled for the gateway, we need to enable ovs_use_veth
to ensure that rate limiting will work inside of the namespace.
Change-Id: I1cbbcde27e4a9edac40ff0fe4086894c7b601087
Neutron team has reportedly addressed issues with uWSGI for the service
including OVN within [1]. Solution requires deployment of 2 new services
while one should be running whenever WSGI is used, where second is
needed specifically for OVN scenario.
neutron-ovn-maintenance-worker is conditionally enabled to avoid
systemd service deployment for non-OVN scenarios, as we do not support
switching neutron_plugin_type back and force at the moment.
[1] https://bugs.launchpad.net/neutron/+bug/1912359
Depends-On: https://review.opendev.org/c/openstack/openstack-ansible/+/935664
Change-Id: I9340d1dc94a6aa1a962bdc10b97439aa1fdc8658
WIth [1] being merged, behaviour of LR binding has changed depending
on the underlying external network, which good to mention in our docs.
[1] https://review.opendev.org/c/openstack/neutron/+/909194
Change-Id: Ica7124760221644dda6ae93ef9ece551b3978ab7
This mainly affects neutron-rpc-server service, which intended to stay
disabled/stopped.
While we've introduced logic in vars, which is respected by systemd role
it is not respected by the role handlers, which brings service back up
running unconditionally.
This actually breaks neutron behaviour after merging of [1], which relies
on neutron-rpc-server being disabled.
[1] https://review.opendev.org/c/openstack/openstack-ansible-os_neutron/+/927881
Change-Id: I28c928362ef009c1b49673005463b653d038faf9
Current command/shell modules for ovn cluster setup while fetching
current deployment state do not actually have changed_when: false
which causes these tasks to end up in "Changed" state
Change-Id: Id4b947d0b7aaa54eb3bbe58d2593ad6b49009b5c
In case VPNaaS driver is enabled ipsec process also runs as part of the
l3 agent service and should not be touched by the handler.
Change-Id: I86655567810c61dbed0415afd2e7ff343f20c736
During OpenStack upgrades we need to ensure that no process is running
with the old code base. For that we used to kill L3 agent processes
except ones running haporoxy/keepalived.
However that handler was broken with migration of systems to cgroupsv2
as it was relying on a filepath for cgroups.
As all modern operating systems already migrated to cgroupsv2 or use
them in compatability mode, let's detect the actual path and use it
instead of the hardcoded one.
Change-Id: I717f3cf13a8001a1f2077a325c4ec451f45f9f74
While we are supposed to move Neutron fully to uWSGI usage from current
eventlet for 2024.2 release, in order to make change backportable we
are disabling uWSGI usage for Neutron API by default as it requires
more services to run, which were added just for 2024.2 cycle.
All prior releases are still expected to run old eventlet version to
avoid any potenital issues.
[1] https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/thread/SVP3VUCOZGIY63TGD33H6NQ6UBAFDN5V/
Change-Id: I5bea4bf1946f9788d9d87561da15c3abdcba1993
With change of the user under which ovn-metadata service is
running from root to neutron, it was clean forgot to change an
ownership for existing configuration produced be the service during
upgrades.
This patch adds an extra folder defenition that should ensure ownership
being correct for all files related to the ovn-metadata-proxy service.
Closes-Bug: #2077684
Change-Id: I8e82558fce8a420dca5fb5302dd5f73e40230e48
This implements a standalone variable which allows to re-define or
extend a list of enabled neutron extensions.
Change-Id: I5476fe856ffa02c60490976c359d3d81e5d9d393
Rename the 'neutron-policy-overrides' tag to 'neutron-policy-override'
so that it's consistent with the other tagged task in this role and all
other openstack-ansible service roles.
Change-Id: I7af67908920bf386d204e28cbf5b936fea76ecd0
With ansible-core 2.16 a breaking changes landed [1] to some filters
making their result returned in arbitrary order. With that, we were
relying on them to always return exactly same ordered lists.
With that we need to ensure that we still have determenistic behaviour
where this is important.
[1] https://github.com/ansible/ansible/issues/82554
Change-Id: I9cdc2ba3679e0dc7fc1f7636ae9efb90984c4652
There is no reason to perform that kind of delegation, as handler should
run only for one host out of the play anyway.
Even more, this delegation might cause failures in case of running role
with limits, as `neutron_bin` on play host may not exist on the
delegated host during minor upgrades, for instance.
Change-Id: Ic8d8aae75dd58a30cd41327fe62009cc0dfb8bbb
Due to the shortcoming of QManager implementation [1], in case of uWSGI
usage on metal hosts, the flow ends up with having the same
hostname/processname set, making services to fight over same file
under SHM.
In order to avoid this, we prepend the hostname with a service_name.
We can not change processname instead, since it will lead to the fight
between different processes of the same service.
[1] https://bugs.launchpad.net/oslo.messaging/+bug/2065922
Change-Id: Id7a52f7e7ebb658b7a5af914d4101be4632022c8
<service>-config tags are quite broad and have a long execution
time. Where you only need to modify a service's '.conf' file and
similar it is useful to have a quicker method to do so.
Change-Id: I8cc76005915afc5ae16a8df0b8ced4e1b1807f09
During last release cycle oslo.messaging has landed [1] series of extremely
useful changes that are designed to implement modern messaging
techniques for rabbitmq quorum queues.
Since these changes are breaking and require queues being re-created,
it makes total sense to align these with migration to quorum queues by default.
[1] https://review.opendev.org/q/topic:%22bug-2031497%22
Change-Id: I6f1131cb9c8f15d7d9367397ff8ca1b439d66ab0
In order to be able to globally enable notification reporting for all services,
without an need to have ceilometer deployed or bunch of overrides for each
service, we add `oslomsg_notify_enabled` variable that aims to control
behaviour of enabled notifications.
Presence of ceilometer is still respected by default and being referenced.
Potential usecase are various billing panels that do rely on notifications
but do not require presence of Ceilometer.
Change-Id: Idd3bb9a0ab58307b6acced6dd60fce3adf17b138
In order to allow definition of policies per service, we need to add variables
to service roles, that will be passed to openstack.osa.mq_setup.
Currently this can be handled by leveraging group_vars and overriding `oslomsg_rpc_policies` as a whole, but it's not obvious and
can be non-trivial for some groups which are co-locating multiple services
or in case of metal deployments.
Change-Id: If239bee6267b983cf335c37ce9fb26bd352a3921
The package provides the following plugins for strongSwan.
- agent (RSA/ECDSA private key backend connecting to SSH-Agent)
- gcm (GCM cipher mode wrapper)
- openssl (Crypto backend based on OpenSSL, provides
RSA/ECDSA/DH/ECDH/ciphers/hashers/HMAC/X.509/CRL/RNG)
Change-Id: Id459831d936a60843a2c07d79c97a1b6aeaa6126
This patch adjusts the whitespace insertion so a space between the
--config-file instances is not trimmed anymore
Change-Id: Ia1507f03febd5bdba18610909f5c3856976566b4
In order to connect to NB/SB leader it requires quite some parameters
to be passed to the CLI. To simplify that we define an environment variables
that are used as defaults once /root/ovnctl.rc is sourced.
Change-Id: Ia44829a48b4b73a81c82b79bc8898c1a95989aef
