Change-Id: I00ee10bdc7f8c1b6ab8576115c757e27b6c2c397
Story: 2005809
Task: 33549

Both docs-on-readthedocs and build-openstack-sphinx-docs contain a build
job - a different one: the current openstack-tox-docs and the obsolete
build-openstack-sphinx-docs. Remove the obsolete template and thus
avoid building docs twice for each change.

Change-Id: I358641d29304815eec6c699ae7e20da1e069443d

Change-Id: I793251519a5da0e3d1225673c9b3394e738f4336
Signed-off-by: Radosław Piliszek <radoslaw.piliszek@gmail.com>

Uses the support [1] for database backups added to Kolla Ansible in the
Stein release.

Adds the following new commands:

kayobe overcloud database backup [--incremental]
kayobe overcloud database recover [--force-recovery-host <host>]

The recovery command is for recovering a clustered database that has
lost quorum.

[1] https://docs.openstack.org/kolla-ansible/latest/admin/mariadb-backup-and-restore.html

Change-Id: Ie16354cd01ea7dd83cd3d4058dd8451b8387600b
Story: 2005015
Task: 29493

Change-Id: I8005dd608bbaed3fcafcce56fc5dd9c307434a77

Change-Id: I4ddf077913ddc620c60c78ca491e70b2e8f59489

Change-Id: I1f76056254454abe2e4dbc49bdb694a67b464299

This was found not to work, and prevents releases from being made.

The cause of the issue is that the trigger-readthedocs-webhook job (in
project-config) is marked as 'final', meaning that a non-trusted Zuul
config source can't override its variables. Instead, you're supposed to
use the trigger-readthedocs-webhook project template, but only one
instance of this can be instantiated by design.

Let's revert to manually updating the release notes for now.

Change-Id: I271c972c7fdde23085f3026137806bb1e3048e5e

```yaml:frontmatter

1. Gather facts for localhost in kolla-ansible.yml
2. Don't include unconfigured networks in network_interfaces
3. Added Keystone configuration extra config merge

```

1. Facts are necessary for the kolla-ansible role,
which references the ansible_user_uid fact

2. It is possible to skip configuring a network,
by setting its name to None

This is done in networks.yml as follows:

admin_oc_net_name:

Currently, these networks may still be included in the 'network_interfaces'
list for each host, despite the fact that they are not in use.

A classic example is when ironic is not enabled, it is currently still
necessary to define provisioning and cleaning networks.

This change avoids including any networks that have their name set to None
in network_interfaces.

3. Added support for Keystone custom configuration

Added tests and documentation to add support for keystone extra configuration

Co-Authored-By: Mark Goddard <mark@stackhpc.com>

Change-Id: Iaa304221b8093ac71f9cdbb23edc84d1517578da

Change-Id: I2495c97455e40cf1f0573cee6ae845da14d762b5

Change-Id: Idf94a64b70d4684a75ec8e8ccc38d64fa6274431

Include information on how to test bare metal instance creation.

Change-Id: Ie40f258a31d4b72cd9867d321a3ff712522daec5

Currently we configure daemon.json to use either devicemapper or overlay
as the storage driver. We should simply pass through whatever is
configured for docker_storage_driver.

Change-Id: Id4423030b5483fe4ecd4f324bc25800e5444fd63
Story: 2005649
Task: 30932

Adds a new abstract parent job for the following kayobe deploy jobs:

kayobe-overcloud-centos
kayobe-overcloud-upgrade-centos
kayobe-seed-centos
kayobe-seed-upgrade-centos

This parent includes commonly used variables, and pre-run and post-run
playbooks for preparing and executing diagnostics, plus other
initialisation.

Change-Id: I9ab89fbc49bb32d86af56d50ec3914740e65d0f8

In [files] section of setup.cfg there is not allowed comment, which
breaks installation with setup.py.

Change-Id: I38fce0a6c155e4b7d2ff7a2535f18e8adc2566e9
Story: 2005546
Task: 30692

Change-Id: Ibf099c6fe4ad516f29d1f4f500f381f4f1baa212

The project infrastructure is now hosted at opendev.org.

Kayobe projects have been moved from the openstack/ namespace to x/.

Change-Id: I16b523285eb34c1cd0eaf920aa4512d0ae1b4f05

In a deployment that has both Ceph or Swift deployed it can be useful to seperate the network traffic.
This change adds support for dedicated storage networks for both Ceph and Swift. By default, the storage hosts are
attached to the following networks:

* Overcloud admin network
* Internal network
* Storage network
* Storage management network

This adds four additional networks, which can be used to seperate the storage network traffic as follows:

* Ceph storage network (ceph_storage_net_name) is used to carry Ceph storage
  data traffic. Defaults to the storage network (storage_net_name).
* Ceph storage management network (ceph_storage_mgmt_net_name) is used to carry
  storage management traffic. Defaults to the storage management network
  (storage_mgmt_net_name).
* Swift storage network (swift_storage_net_name) is used to carry Swift storage data
  traffic. Defaults to the storage network (storage_net_name).
* Swift storage replication network (swift_storage_replication_net_name) is used to
  carry storage management traffic. Defaults to the storage management network
  (storage_mgmt_net_name).

This change also includes several improvements to Swift device management and ring generation.

The device management and ring generation are now separate, with device management occurring during
'kayobe overcloud host configure', and ring generation during a new command, 'kayobe overcloud swift rings generate'.

For the device management, we now use standard Ansible modules rather than commands for device preparation.
File system labels can be configured for each device individually.

For ring generation, all commands are run on a single host, by default a host in the Swift storage group.
A python script runs in one of the kolla Swift containers, which consumes an autogenerated YAML config file that defines
the layout of the rings.

Change-Id: Iedc7535532d706f02d710de69b422abf2f6fe54c

This commit was bulk generated and pushed by the OpenDev sysadmins
as a part of the Git hosting and code review systems migration
detailed in these mailing list posts:

http://lists.openstack.org/pipermail/openstack-discuss/2019-March/003603.html
http://lists.openstack.org/pipermail/openstack-discuss/2019-April/004920.html

Attempts have been made to correct repository namespaces and
hostnames based on simple pattern matching, but it's possible some
were updated incorrectly or missed entirely. Please reach out to us
via the contact information listed at https://opendev.org/ with any
questions you may have.

Adds two new variables, 'openstack_release' and 'openstack_branch',
in ${KAYOBE_CONFIG_PATH}/openstack.yml for setting the current OpenStack
release and branch in a single place.

Also uses the master branch for the molecule tox job.

Change-Id: I851a1e6eddc6738005c1813599445b38c0ae0d57

Use master branch of:

* Kolla
* Kolla ansible
* Bifrost
* IPA
* OpenStack services
* Requirements

Also, use the infra docker registry mirror at port 8082 which does not
have any path component in its URL, and so works with Docker CE.

Depends-On: https://review.openstack.org/#/c/651254/
Change-Id: Icdb62aa0083d9272a08421138719cf5f6b52ec5a
Story: 2001864
Task: 14316

This is supported in kolla-ansible via the ironic_inspector_pxe_filter
variable, which can be added to globals.yml. The default value for that
variable changed in the Stein release from 'iptables' to 'dnsmasq',
since the iptables filter does not work with Docker CE [1].

This change removes the inspector_manage_firewall variable.

This change also adds an iptables rule in CI tests to allow DHCP packets
to be forwarded, to ensure bare metal servers can be deployed.

[1] https://bugs.launchpad.net/kolla-ansible/+bug/1823044

Depends-On: https://review.openstack.org/649673
Change-Id: Idac6777b4d97fbd17698fc2086ceb068d7b2e326
Related-Bug: #1823044

If you enable monasca via kolla_enable_monasca, grafana is automatically
enabled too. Monasca provides its own forked version of grafana, so we
don't need the standard one.

This change brings the logic into line with kolla-ansible.

Change-Id: I5be1f269547d9c547211b675814829a665685485
Story: 2005399
Task: 30393