During the Train cycle, Bifrost switched to using JSON-RPC by default
for Ironic's internal communication [1], avoiding the need to install
RabbitMQ. This simplifies things, so we may as well remove our custom
configuration of RabbitMQ.
[1] https://review.openstack.org/645093
Change-Id: I3107349530aa753d68fd59baaf13eb7dd5485ae6
Since we are now in the Train cycle, we can be sure that any running
MariaDB containers can be safely stopped, and we do not need to perform
an explicit shutdown prior to restarting them.
Change-Id: I5450690f1cbe0c995e8e4b01a76e90dac2574d61
Related-Bug: #1820325
Now that the stable/stein branch has been cut, we can set the previous
release to Stein. This is done in kolla-ansible for rolling upgrades,
and in CI configuration for upgrade tests.
Change-Id: I87269738db9521fc22a6ce3aee67d9ab00d47e2a
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
After upgrade we should check if OVSDB doesn't need conversion to new
version - this patch adds that to ovsdb start script.
Change-Id: Ifa8766d050b506708142a1970121ce5944c6bae1
Closes-Bug: #1792496
incorrect path when generating certificates.
The 'setting permissions on key' task fails because the task looks for
the haproxy.key in an invalid path. The certificates_dir is defined as
'{{ node_config }}/certificates' in the main.yml . The 'Setting
permissions on Key' task has a path of '{{ certificates_dir
}}/certificates/private/haproxy.key which is incorrect. Removing the
'certificates' in the path corrects this problem and allows the user to
successfully create certificates using 'kolla-ansible certificates'.
Change-Id: I37b10b994b05d955b6f67c908df1472231a91160
Closes-Bug: 1821805
The synced flush fails due to concurrent indexing operations.
The HTTP status code in that case will be 409 CONFLICT. We can
retry this task until returns success.
Change-Id: I57f9a009b12715eed8dfcf829a71f418d2ce437b
When kolla-ansible bootstrap-servers is run, it executes one of the
following two tasks:
- name: Ensure node_config_directory directory exists for user kolla
file:
path: "{{ node_config_directory }}"
state: directory
recurse: true
owner: "{{ kolla_user }}"
group: "{{ kolla_group }}"
mode: "0755"
become: True
when: create_kolla_user | bool
- name: Ensure node_config_directory directory exists
file:
path: "{{ node_config_directory }}"
state: directory
recurse: true
mode: "0755"
become: True
when: not create_kolla_user | bool
On the first run, normally node_config_directory (/etc/kolla/) doesn't
exist, so it is created with kolla:kolla ownership and 0755 permissions.
If we then run 'kolla-ansible deploy', config files are created for
containers in this directory, e.g. /etc/kolla/nova-compute/. Permissions
for those files should be set according to 'config_owner_user' and
'config_owner_group'.
If at some point we again run kolla-ansible bootstrap-servers, it will
recursively set the ownership and permissions of all files in /etc/kolla
to kolla:kolla / 0755.
The solution is to change bootstrap-servers to not set the owner and
permissions recursively. It's also arguable that /etc/kolla should be
owned by 'config_owner_user' and 'config_owner_group', rather than
kolla:kolla, although that's a separate issue.
Change-Id: I24668914a9cedc94d5a6cb835648740ce9ce6e39
Closes-Bug: #1821599
Upgrading MariaDB from Rocky to Stein currently fails, with the new
container left continually restarting. The problem is that the Rocky
container does not shutdown cleanly, leaving behind state that the new
container cannot recover. The container does not shutdown cleanly
because we run dumb-init with a --single-child argument, causing it to
forward signals to only the process executed by dumb-init. In our case
this is mysqld_safe, which ignores various signals, including SIGTERM.
After a (default 10 second) timeout, Docker then kills the container.
A Kolla change [1] removes the --single-child argument from dumb-init
for the MariaDB container, however we still need to support upgrading
from Rocky images that don't have this change. To do that, we add new
handlers to execute 'mysqladmin shutdown' to cleanly shutdown the
service.
A second issue with the current upgrade approach is that we don't
execute mysql_upgrade after starting the new service. This can leave the
database state using the format of the previous release. This patch also
adds handlers to execute mysql_upgrade.
[1] https://review.openstack.org/644244
Depends-On: https://review.openstack.org/644244
Depends-On: https://review.openstack.org/645990
Change-Id: I08a655a359ff9cfa79043f2166dca59199c7d67f
Closes-Bug: #1820325
After upgrading from Rocky to Stein, nova-compute services fail to start
new instances with the following error message:
Failed to allocate the network(s), not rescheduling.
Looking in the nova-compute logs, we also see this:
Neutron Reported failure on event
network-vif-plugged-60c05a0d-8758-44c9-81e4-754551567be5 for instance
32c493c4-d88c-4f14-98db-c7af64bf3324: NovaException: In shutdown, no new
events can be scheduled
During the upgrade process, we send nova containers a SIGHUP to cause
them to reload their object version state. Speaking to the nova team in
IRC, there is a known issue with this, caused by oslo.service performing
a full shutdown in response to a SIGHUP, which breaks nova-compute.
There is a patch [1] in review to address this.
The workaround employed here is to restart the nova compute service.
[1] https://review.openstack.org/#/c/641907
Change-Id: Ia4fcc558a3f62ced2d629d7a22d0bc1eb6b879f1
Closes-Bug: #1821362
When Nova, Glance, or Cinder are deployed alongside an external Ceph deployment
handlers will fail to trigger if keyring files are updated, which results in the
containers not being restarted.
This change adds the missing 'when' conditions for nova-libvirt, nova-compute,
cinder-volume, cinder-backup, and glance-api containers.
Change-Id: I8e183aac9a72e7a7210f7edc7cdcbaedd4fbcaa9
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
RDO is packaging placement-api with bundled httpd config
and it conflicts with kolla-ansible generated one.
Change-Id: I018a4ed1b2282e8a789b63e3893e61db2fde8cf2
Reconfiguring Swift currently fails to restart containers if
configuration changes. This is because kolla_set_configs is executed in
the containers as the default swift user, which does not have permission
to access all necessary files.
This change uses the root user to execute the command instead, which
allows it to exit with the correct status of 1 if the config files
differ.
Change-Id: I2a2363c71430a7173bb5253662412ae5dba09654
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
All Prometheus services should use the Prometheus install type which
defaults to the Kolla install type, rather than directly using the
Kolla install type.
Change-Id: Ieaa924986dff33d4cf4a90991a8f34534cfc3468
The api_endpoint option was deprecated, and will be removed by
https://review.openstack.org/643483.
Change-Id: Ie56a8ab07ab21d2e7d678e636c1408099d8ab3aa
Fix filemode in the merge_configs and merge_yaml action plugin to
be compatible with python3
Change-Id: Ief64c5bdcd717141281e23c255a49ec02a96aef2
Closes-Bug: #1820134