The recent addition of this flag make the configuration
of stand-alone Monasca slightly simpler.

Change-Id: Ib4c03926daa3f0f3de0fa4412cd785d87ed5500c

Add file to the reno documentation build to show release notes for
stable/stein.

Use pbr instruction to increment the minor version number
automatically so that master versions are higher than the versions on
stable/stein.

Change-Id: I4a9a0eab03f3dd06bf2214ed6d6e8db6af5bd032
Sem-Ver: feature

This is how services reach mariadb; verify it that way.

Closes-Bug: #1823005
Change-Id: I9924ad050118b8a853e2309654a089f65178cd77

This patch fixes Heat deployment with TLS self-signed certs.

Change-Id: Iadf67d1a5eb2b771e34d27fbced5aad15f271822
Closes-Bug: #1822990

Typically, non-executable files should have 660 or 600 and executable
files and directories should have 770. All should be owned by the
'config_owner_user' and 'config_owner_group' variables.

This change adds a script to check the owner and permissions of config
files under /etc/kolla, and runs it at the end of CI jobs.

Change-Id: Icdbabf36e284b9030017a0dc07b9dc81a37758ab
Related-Bug: #1821579

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

ipc_mode: host should be set for manila share when using LVM driver[1].

[1]: https://docs.openstack.org/manila/latest/install/install-share-rdo.html

Change-Id: If57e623f381f8de1e1433916f2ec37455ad3becd
Closes-bug: #1822713

the action show be kolla_action in kolla-ansible/cyborg
Closes-bug: #1822555
Change-Id: I3dd909ae785dd43d5faabbc3fdd5f8bb8aca370b

Change-Id: I0d66e49f09313de8abb89f510c7a5098507c572a

"v3" is supposed to be part of the OPENSTACK_KEYSTONE_URL:
https://docs.openstack.org/horizon/latest/admin/customize-configure.html#configure-the-dashboard

Closes-Bug: #1822257

Change-Id: I5fd2d36305172d351fbfa9141c7cbc7c5af98f3b

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

This patch adds two new jobs:

* kolla-ansible-centos-source-upgrade
* kolla-ansible-ubuntu-source-upgrade

These jobs first deploy a control plane using the previous release of
Kolla Ansible, then upgrade to the current release.

Because we can't change the branch of the git repository on the Zuul
executor, we change the branch of the kolla-ansible repository on the
primary node to the branch of the previous release, in this case
stable/rocky. A new remote-template role has been added that supports
generating templates using a remote template source, to generate config
files using the previous kolla-ansible branch.

If the change being tested depends on a kolla change for the current
branch, then we build images. Rather than using the current
kolla-ansible version to tag the images, we now tag them with
change_<gerrit change ID>. This is because the version of kolla-ansible
will change from the previous release to the current one as we upgrade
the system.

Finally, it should be noted that the 'previous_release' variable in the
Zuul config needs to be updated with each release, since this sets the
release of kolla-ansible that is installed initially.

Depends-On: https://review.openstack.org/645089/
Depends-On: https://review.openstack.org/644250/
Depends-On: https://review.openstack.org/645816/
Depends-On: https://review.openstack.org/645840/
Change-Id: If301e0affcd55360fefe3b105f023ae5c47b0853

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

more infomation, refer to the panko docs[1] or code[2]

[1]: https://docs.openstack.org/panko/rocky/install/manual.html
[2]: https://github.com/openstack/panko/blob/9c4677f1784ed3353c31067e6e1bf74a0c86c037/panko/storage/__init__.py#L39

Change-Id: Ic7bdf555eb262005ca24f675cd8cee09d9bc3092
Closes-Bug: #1690843

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

Currently ceph jobs are often getting TIMED_OUT, increasing limit.

Change-Id: I3c6684984930d55a56da846bd8c3f19df2754b06

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