The nova_force_config_drive variable was removed several releases ago.
Update the docs to only mention using nova_nova_conf_overrides to
disable the config drive.
Change-Id: I1565e1e6e7b8fe12a6b70f09947c48cc893d3ef5
oslo_messaging isn't set up to handle this situation and appears
to expect the node to come back (as would happen during a version
upgrade). As a result, client processes don't attempt to re-create
queues which lived on the node being upgraded. This situation
doesn't auto-recover which can be very disruptive.
Change-Id: I608202d665417682ce7309bb9bf4b52a2cf4373e
Prior doc was misleading on a way how to re-bootstrap galera cluster.
It's now updated with relevant iinformation, that should trigger bootstrap
and rolling restart of the cluster.
Closes-Bug: #1927148
Change-Id: I0aee053cc6fcd6c8eb2261c20dba4e338ff61735
There is actually no need in extra manual actions for primary node, except
override what primary node actually is.
Change-Id: Ibaba5f28551e98c805c988ab52b33c5eb1b98e86
Sicne 2023.1 we have started configuring haproxy backends per service
during specific playbook runtime. While it works in general, it requires
some extra steps to be run for upgrades to avoid race conditions,
when keepalived selects host as active that does not have any
backends configured.
To avoid this we suggest running haproxy with skipping keepalived
installation and proceed with backends configuration.
Change-Id: I37d9b25ae996bc66f69a7aad7a0ba13c32abc929
At the moment there is no well defined way to supply list of extra Python
requirements for Ansible venv. However, some collections for their work might
require presence of extra libraries inside the execution environment.
While PIP_OPTS might be used right for that, it's usage is not transparent
or documented.
In order to handle such need, `user-ansible-venv-requirements.txt ` is being implemented
that reside inside OSA_CONFIG_DIR and contains list of required packages
for installation when running bootstrap-ansible.sh
Change-Id: Ic99f7eff200e2e672dcc3edd875b155af84232b7
Right now our documentation assumes that users must run
OpenStack-Ansible as root users. With that it's not a
strict requirement and there is a pretty much
straightforward way on running playbooks as non-root
user by leveraging Ansibles' `become`.
Depends-On: https://review.opendev.org/c/openstack/ansible-role-python_venv_build/+/897948
Change-Id: I426c78157a17fd4524e48437c6f632a8551223d0
Since OVN is current default, it makes sense to have it first in the doc,
followed by alternatives like OVS and LXB
Change-Id: I444938d930bc60be378dc0434a4c3f2de67b4061
Having language set to None results in a warning since it is not an
appropriate lagnuage name. Setting it to the default 'en'.
Change-Id: I6579d1ef078e24eabce9051a7907bf6a3db7b9a8
At the moment our documentation does not contain any steps that
should be made to create EOL or EM releases. With that existing
releasing documentation is slightly outdated and not fully reflect
actions that should be made during periodic work.
Change-Id: I0223bcb4424aef0f884f901f102953540f2b04c3
Despite Yoga is an unofficial SLURP release, we're preparing all tooling
and test upgrades from Y to 2023.1. With that we're mentioning
in docs, that upgrade from Y is possible. We also update release names
that are used in docs.
Change-Id: I41eb336016920624bbf0fa7641301c64cce1070a
Enabling TLS on the internal VIP for existing deployments will cause
downtime until each client is configured to use HTTPS instead of HTTP.
To avoid downtime, it is recommended to enable
`openstack_service_accept_both_protocols` until all services are
configured correctly.
It allows haproxy frontends to accept both HTTP and HTTPS.
Depends-On: https://review.opendev.org/c/openstack/openstack-ansible-haproxy_server/+/864784
Change-Id: Ie6f5b73c54b0a6d1f661a9d4f33b8a301d8c4170
In cases when SSH and mgmt networks are different, it might be important
to have valid management_address that services are relying on when
listening on interfaces. At the moment for bare metal hosts
management_address will be equal to ansible_host which leads to
unpredictable behaviour under some scenarios. With management_ip we allow
to define another IP address that will be used as container/management
address for bare metal host, while `ip` will still represent
ansible_host.
Related-Bug: #2002645
Change-Id: I3152ae7985319e85b9ea520021f9eea6f5850341
This patch aims to reduce confusion caused by a variable
`container_address` that's applicable for bare metal hosts. With that
it renames `is_container_address` to `is_management_address`
to be aligned with the purpose of the variable, as `container` part
raised confusion.
Change-Id: I314224f3376cf91e05680b11d225fdaf81ec32ab
At the moment it's not possible to apply different versions of
services to the different groups due to playbook vars having
prescedence over group_vars. However, it can be quite important
to such use cases, for example for phased rollouts of newer versions.
This will also reduce amount of unnecessary variables that are included
for each host, since only required git details will be loaded.
Closes-Bug: #2007296
Depends-On: https://review.opendev.org/c/openstack/openstack-ansible-os_rally/+/881954
Change-Id: Icaa3a958926d9f9aa6cb649bd9f3da9449dd7490
I've stopped proposing PRs to original repos as their review
takes really a while now.
With that I'm updating location of current version of tooling.
Change-Id: Ie4f168fbe3f2b0bc74aef3ca0700b2cffdbf752a
James Denton