Adds the command ``kayobe overcloud service configuration validate`` to
run the ``oslo-config-validator`` on all hosts via Kolla-Ansible. The
output directory of the results is specified with the flag
``--output-dir``.
Change-Id: I5d5d16eeabe69e8659e33722165928df096b3559
In Zed cycle, we have dropped the python 3.6/3.7[1] testing
and its support. Removing the py36 centos8 job as well as
updating the python classifier also to reflect the same.
[1] https://governance.openstack.org/tc/reference/runtimes/zed.html
Change-Id: I1bd306698a0b2afd1b824eda3389fcc3f919a1fb
As a first step towards supporting multiple overcloud disk images, this
change introduces a new command to build a disk image directly with DIB:
`kayobe overcloud host image build`.
It also disables building a root disk image during Bifrost bootstrap if
overcloud_dib_build_host_images is set to true.
Change-Id: I93d242889e225b4e60254f6b9cc5eeb457294ac8
Story: 2002098
Task: 41693
This change allows you to define additional VMs to deploy
on the seed-hypervisor.
Co-authored-by: Piotr Parczewski <piotr@stackhpc.com>
Co-authored-by: Will Szumski <will@stackhpc.com>
Co-authored-by: Mark Goddard <mark@stackhpc.com>
Story: 2008741
Task: 42095
Change-Id: I8055fc5eb0a9edadcb35767303c659922f2d07ca
Ansible facts can have a large impact on the performance of the Ansible
control host. This patch introduces some control over which facts are
gathered (kayobe_ansible_setup_gather_subset) and which facts are stored
(kayobe_ansible_setup_filter). By default we do not change the default
values of these arguments to the setup module. The flexibility of these
arguments is limited, but they do provide enough for a large performance
improvement in a typical moderate to large OpenStack cloud.
In particular, the large complex dict fact for each interface has a
large effect, and on an OpenStack controller or hypervisor there may be
many virtual interfaces. We can use the kayobe_ansible_setup_filter
variable to help:
kayobe_ansible_setup_filter: 'ansible_[!qt]*'
This causes Ansible to collect but not store facts matching that
pattern, which includes the virtual interface facts. Currently we are
not referencing other facts matching the pattern within Kayobe.
Note that including the 'ansible_' prefix causes meta facts module_setup
and gather_subset to be filtered, but this seems to be the only way to
get a good match on the interface facts. To work around this, we use
ansible_facts rather than module_setup to detect whether facts exist in
the cache.
The exact improvement will vary, but has been reported to be as large as
18x on systems with many virtual interfaces.
This change also introduces a new command to gather facts for Kayobe &
Kolla Ansible on demand, 'kayobe overcloud facts gather'. This can be
used to populate a fact cache.
Depends-On: https://review.opendev.org/c/openstack/kolla-ansible/+/794610
Story: 2007993
Task: 42586
Change-Id: I5ce3c734433e1682ee942867505468c57440e689
Setuptools v54.1.0 introduces a warning that the use of dash-separated
options in 'setup.cfg' will not be supported in a future version [1].
Get ahead of the issue by replacing the dashes with underscores. Without
this, we see 'UserWarning' messages like the following on new enough
versions of setuptools:
UserWarning: Usage of dash-separated 'description-file' will not be
supported in future versions. Please use the underscore name
'description_file' instead
[1] https://github.com/pypa/setuptools/commit/a2e9ae4cb
Change-Id: I831f08154dad5a80e8f34aeb9ae161d2de5ffa57
Sometimes there is a need to develop site specific playbooks. Currently,
it is necessary to manually invoke these at the right point during the
deployment. Adding the ability to automatically run these custom
playbooks will reduce the chance of running these playbooks at the wrong
point or forgetting to run them at all.
Change-Id: I1ae0f1f94665925326c8b1869dd75038f6f1b87d
Story: 2001663
Task: 12606
Removes and/or replaces all mentions of py27.
Cleans up obsolete requirements and their lower-constraints.
Update cliff minimum to 3.1.0 in requirements.txt, which has a fix for
story 2005891.
Change-Id: I52cffa2f1aee944f79c4618ea20b779755792f2a
Kolla ansible train adds a new command, kolla-ansible deploy-containers,
that will only deploy containers, and skips registration, bootstrapping
and configuration.
This change adds a new 'kayobe overcloud service deploy containers'
command to make use of the new kolla-ansible command.
Change-Id: I999dfe4b1d082bc88148f54b236644abcbd96a5a
Story: 2006951
Task: 37633
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
In [files] section of setup.cfg there is not allowed comment, which
breaks installation with setup.py.
Change-Id: I38fce0a6c155e4b7d2ff7a2535f18e8adc2566e9
Story: 2005546
Task: 30692
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 adds the ansible playbooks required by kayobe to the manifest by
using the data_files option in setuptools. When using pip to install
kayobe into a virtualenv, these files will be placed in
<venv>/kayobe/share/.
In an editable install, e.g using `pip install -e .`, data_files are not
installed into the virtualenv. Instead, we must follow the egg-link file
to find out the actual location.
Story: 2004252
Task: 27787
Change-Id: Ibef040eceb547476007f83c0d5dcdb2bc6986d1e
Adds a new command to upgrade containerised services on the seed:
kayobe seed service upgrade
This is largely the same as the deploy command, since there is no
kolla-ansible bifrost-upgrade command yet.
A limitation in Bifrost requires us to remove IPA images before
upgrading the bifrost container.
Change-Id: Ibbe01e972487e69dbb753a67efcf13e3ae0800de
Story: 2004308
Task: 27872
Without this change twine check dist/* would fail as this was
producing a double new line. The rest of the PKG-INFO would then
be interpreted as the message body and become the long
description. See https://github.com/pypa/twine/issues/422 for
more details.
This fixes the test-release-openstack-python3 zuul job.
TrivialFix
Change-Id: If1330c4824e949aa427475dfcc26218fb398a66e
This will update the the deploy_ramdisk and
deploy kernel properties of 'Driver info'
field on Ironic nodes if the locally built
or externally referenced images are updated.
Change-Id: Id3997db452dde6e6e242a9b1091cb219c53ebda1
Kayobe is to become an OpenStack-related project, and as such will use
Gerrit for code reviews and Storyboard for issue and feature tracking.
The README and CONTRIBUTING documents have been updated to reflect that,
and a standard OpenStack HACKING document has been added.
Change-Id: Id03bcb5183bfbf6e84bb4d9c22f85d9418b6b4fc
Story: #2001637
Task: #6644
Python Build Reasonableness (PBR) [1] is used by most OpenStack projects
for building python packages, so we should fall into line here.
[1] https://pypi.python.org/pypi/pbr
Change-Id: Ic74a62eeb65e7158ce75a082e68652c2e50a2a91
Story: #2001637
Task: #6648
