Change-Id: I3395810f353c1a26eafcf0b97eb416d7083efde1

Change-Id: I89313d7c279f95e80c593cf02309c8a9f8e6e318
Signed-off-by: ZijianGuo <guozijn@gmail.com>

The flush_handlers clause doesn't honour conditional clauses.
Instead, it prints a warning and runs anyway:
[WARNING]: flush_handlers task does not support when conditional

See: https://github.com/ansible/ansible/pull/41126

TrivialFix

Change-Id: Iaf70c2e932ae6dfb723bdb2ba658acdbfe74ebe2

deflate is disable because of breach attach[0] issue. But it has be
fixed on horizon size through[1], so we cloud enable deflate all the
time.

compress application/json too in default.

[0] https://wiki.openstack.org/wiki/OSSN/OSSN-0037
[1] https://review.openstack.org/#/c/596549/

Change-Id: I364c8a71633fac846dbaac8eaa0b78191e6d7d0e
Closes-Bug: #1827976

This fixes a deprecation warning that gets displayed when running
the kibana/post_config 'Get kibana default indexes' task.

HEADERS_ has been deprecated since ansible 2.1 and will be
removed in 2.9.

https://docs.ansible.com/ansible/latest/modules/uri_module.html

TrivialFix

Change-Id: I177113c606119505c6cb69c66a326f7cbdaf2196

Since Ansible 2.5, the use of jinja tests as filters has been
deprecated.

I've run the script provided by the ansible team to 'fix' the
jinja filters to conform to the newer syntax.

This fixes the deprecation warnings.

Change-Id: I844ecb7bec94e561afb09580f58b1bf83a6d00bd
Closes-bug: #1827370

glance_upgrading variable is defined only during rolling upgrades, but
its value is checked on every call to "Restart glance-api container" handler.

Closes-Bug: #1826511
Change-Id: Idc95306c50a09666ac0a12e975307a42aef9e352

By default, Ceilometer uses gnocchi_resources.yaml as cfg_file that defines
the metric archive policy and metrics send to gnocchi. Users may want to define
their own strategy.

Change-Id: I49ba34588101ac2b4f450067c8c9a354134063bb
Signed-off-by: Ning Yao <yaoning@unitedstack.com>

1.Use opendev.org instead of git.openstack.org.
2.Use review.opendev.org instead of review.openstack.org.

You can see the discussion below:
http://lists.openstack.org/pipermail/openstack-discuss/2019-March/003603.html

Change-Id: Ice4509204df788a1a44a06fb89fb44cfe6b54b94

20 seconds may be too short to wait for grafana ready, Let's keep the
check task 60 seconds.

backport: rocky

Change-Id: Ib219ad215d1ef2147ba3591f8c398feb4f3c8888
Closes-Bug: #1821285

Add a possibility to mount sources as volumes to containers,
in "more than documentation" way. That will let us to use kolla
as a replacement for devstack.

Partially implements: blueprint mount-sources

Change-Id: I4868ed6829bd037e1012d1f40c4a1d1b9995bf95

This change ensures that URLs returned from these services reference
the HAProxy endpoint, rather than the host on which the service is
running.

Closes-Bug: #1825150
Change-Id: I7f966ff749ea37620f1bde7019a598cb9505fa45

Follow up to https://review.openstack.org/#/c/651136/, which fails on
Ubuntu versions prior to 18.04.

Change-Id: I74a85dec95ceed7c6eeafb9eb1920c7c30b3e64a
Related-Bug: #1813492

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

Add become to copy cloud config file for openstack exporter.

Change-Id: I4c0c325e9dd1f41ca2c4667178a4fa674fa23ec5
Closes-Bug: #1824098

1. The Keystone WSGI scripts don't have a python3- prefix, although they
   are using python 3.

2. The Placement WSGI script doesn't have a python3- prefix, although it
   is using python 3.

Depends-On: https://review.openstack.org/651327
Change-Id: I805df8f85634edea8322495ca73897d44967cfe6
Closes-Bug: #1823989

Currently easy_install is not available on Ubuntu 18+ due to [1]. In
that case, install pip via apt rather than easy_install.

[1]
https://bugs.launchpad.net/ubuntu/+source/python-setuptools/+bug/1774419

Change-Id: Id358fdb655d71490b0915680dff131cfe33f4a40
Closes-Bug: #1813492

With Docker CE, the daemon sets the default policy of the iptables
FORWARD chain to DROP. This causes problems for provisioning bare metal
servers when ironic inspector is used with the 'iptables' PXE filter.
It's not entirely clear why these two things interact in this way,
but switching to the 'dnsmasq' filter works around the issue, and is
probably a good move anyway because it is more efficient.

We have added a migration task here to flush and remove the ironic-inspector
iptables chain since inspector does not do this itself currently.

Change-Id: Iceed5a096819203eb2b92466d39575d3adf8e218
Closes-Bug: #1823044

backport: stein

If I deploy monasca by setting enable_monasca to true, the monasca_notification
restarts with the following error:

ERROR:__main__:MissingRequiredSource: /var/lib/kolla/config_files/notification_templates/* file is not found

These templates are optional, so we need to mark this directory as optional in
config.json.

Change-Id: Ia2dd835daa7ab1153617cc92f17c2d8d498c73e0
Closes-Bug: #1823726

Make an early start on the TODOs for the Train cycle.

1. Remove the task that removes the vitrage_collector container, which
   was added in the Stein cycle to clean up this container which is no
   longer deployed.

2. Remove globals.yml configuration in CI to disable Heat for upgrade
   jobs. Heat is now enabled in the previous release (Stein).

3. Remove the deprecated variable cinder_iscsi_helper, which was renamed
   to cinder_target_helper in Stein.

Change-Id: I774bf395e0bdd4db9c20c6289a22cf059fa42e1a

These tasks were only necessary for migrating placement from nova to a
separate service. Since the stable/stein branch has been cut, it is safe
to remove these migration tasks in master.

Change-Id: I4d477efad7ab6247aaff57d31ee83e137eb3f796

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

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

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

"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

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

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

This is used for version pinning during rolling upgrades.

Change-Id: I6e878a8f7c9e0747d8d60cb4527c5f8f039ec15a

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