Periodic jobs don't have zuul.change defined, since there is no change
being tested. This causes an early failure when referencing zuul.change
to set the image tag for built images. In periodic jobs we'll never need
to build images because there is no dependent kolla change under test.
Change-Id: I6d9d81cf17b7d0d7aaf87cd96418c904c46681f2
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
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
* Recommend using a virtual environment
* Fix reference to multinode inventory
* Add explicit use of sudo where necessary
* Change ownership of /etc/kolla to current user
These changes should make it possible to copy/paste from the quickstart
to get a working deployment.
Change-Id: Ib3990f9e16eaa1e19a4ad5bfea5bdb2e4bc1c333
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
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
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
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
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