Often cephadm jobs fail with:
Mar 30 13:01:21 primary bash[75459]: debug 2021-03-30T13:01:21.844+0000 7fa30431f700 -1 error: monitor data filesystem reached concerning levels of available storage space (available: 4% 1.8 GiB)
Let's check if 5G OSD helps and also print df -h output for reference
Change-Id: I6960fd0f378aea5a14a73d9228edf86fb86cac6c
We can't check this with timedatectl as it is not aware
of any "non-native" NTP daemon.
This could be a warning-level message but we don't have
such messages from the prechecks.
Closes-Bug: #1922721
Change-Id: I6db37576118cf5cff4ba7a63e179f0ab37467d22
Kolla Ansible supports configuration of the project used by Octavia to
communicate with other services, via octavia_service_auth_project. Until
Ussuri, this was set to admin. In Ussuri it changed to service. It may
also be set to a different value.
Kolla Ansible currently gives the octavia user the admin role in the
project, but it does not ensure that the project exists. For admin and
service projects, this is not a problem. If the project has been
customised however, it will not necessarily exist, which will cause
Octavia deployment to fail.
This change fixes the issue by ensuring that the service auth project
exists, in addition to the service project.
Closes-Bug: #1922100
Change-Id: I968efbf3ad1de676548b4e3aeefc20bf80ca94a0
host -> host_ip[0]
Remove deprecated configuration notification_topics.
WARNING oslo_config.cfg [-] Deprecated: Option "notification_topics"
from group "DEFAULT" is deprecated. Use option "topics" from
group "oslo_messaging_notifications".
[0]https://docs.openstack.org/cyborg/latest/configuration/sample-config.html
Change-Id: Ia5d53fb60d34c1509c6cdb905cbd0a93dd1c8b3d
For using 3rd party Octavia providers (such as OVN provider) an
octavia-driver-agent container must be running to expose those providers to
use.
OVN CI job has been extended with deploying Octavia and testing OVN Load
Balancer.
Closes-Bug: #1903506
Depends-On: https://review.opendev.org/c/openstack/kolla/+/771191
Change-Id: Ibafa8b7307981f2a51e630cc113d18af6162171c
Now that the issue is fixed upstream, let's remove the workaround.
[1] If3943060b5d09bd153b6401d34c7d10d3dc864fe
Change-Id: I9cbeee5a397d736338ff2065001d9d6be20cb66e
We need to import copy-certs.yml when either copying a CA file into
containers, or when a service has backend TLS enabled. Cinder only
included the former condition. This patch fixes it.
TrivialFix
Change-Id: I70aab86055cadad9abf28956c6d6e8a90a9668c0
