Currently building OVN container images and OVS container images are
mutually exclusive.
This becomes problem when all container images are needed to be built
at the same time.
``kolla_build_neutron_ovs`` is added to let user to build OVS even if
OVN is enabled when it's explictly set to true.
Default value ensures regex mapping behaves normally when
``kolla_build_neutron_ovs`` is not given.
Release note is also added.
Change-Id: I7efe883fce4117a5167b6db4a711004d77a44f81
Changes overcloud_dib_build_host_images to true, as promised in
I93d242889e225b4e60254f6b9cc5eeb457294ac8.
Change-Id: I322432985535348fb4ebe5bff7db5dd68f16b340
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
The critical part of this commit is adapting code that was still
sourcing env-vars. This file was removed from Bifrost in the Victoria
release, breaking the `kayobe seed deployment image build` command.
The other changes are not yet breaking Kayobe:
1) Release notes claim that OpenStackClient is no longer installed when
keystone is not enabled, but it appears to still be available. Use
the ironic native baremetal command instead except in playbooks
related to baremetal compute nodes (i.e. overcloud ironic).
2) The use of OS_CLOUD=bifrost-inspector is deprecated and should be
replaced by OS_CLOUD=bifrost.
Change-Id: I25078e69acdf41a4ef9957f99fe5047de54b778d
Story: 2008558
Task: 41696
* Always use Python 3
* Drop code paths for CentOS 7
* Drop support for Yum
* Remove support for host NTP daemon, always use chrony
* Switch references from 'yum_install_epel' to 'dnf_install_epel'
* Remove overcloud host image workaround for tagged VLAN admin network
* Remove the kayobe.utils.yum_install function, which is unused
Change-Id: I368f6edafed9779658798fc342116b4c1b3ffd48
Story: 2006574
Task: 39481
Hopefully this provides access to relevant information without breaking
the flow.
Change-Id: I40b71cdf782dda6971dafb5894670c30e446ccb0
Story: 2004337
Task: 37387
Ideally we will fix these issues, but documenting them is a good first
step.
Change-Id: I9a840005d62b974f0681ac39e1ff02ae3ff0120e
Story: 2004967
Task: 29410
Also reorder upgrade documentation to make it clear that configuration
migration is something that should be done as a preparatory task.
Change-Id: I97ada3c6fd94a9ab7b5add97e90717f2a56bc8f3
Story: 2006677
Task: 36953
If the kayobe overcloud provision command is executed with overcloud
ironic nodes without names, cloud-init will fail with the following
Traceback when the deployed image boots:
Traceback (most recent call last):
File "/usr/lib/python2.7/site-packages/cloudinit/sources/__init__.py", line 447, in find_source
if s.get_data():
File "/usr/lib/python2.7/site-packages/cloudinit/sources/__init__.py", line 132, in get_data
self._get_standardized_metadata())
File "/usr/lib/python2.7/site-packages/cloudinit/sources/__init__.py", line 110, in _get_standardized_metadata
'local-hostname': self.get_hostname(),
File "/usr/lib/python2.7/site-packages/cloudinit/sources/__init__.py", line 317, in get_hostname
if util.is_ipv4(lhost):
File "/usr/lib/python2.7/site-packages/cloudinit/util.py", line 544, in is_ipv4
toks = instr.split('.')
This is a bug [1] in cloud-init. The symptom is that hosts provision
successfully, but are not accessible via SSH. A solution is to ensure
that all nodes are named.
Until we have a release of CentOS with the cloud-init fix included, we
should at least mention this limitation in our documentation.
[1] https://bugs.launchpad.net/cloud-init/+bug/1852100
Change-Id: If54f56fb9f0b626d9fae80db622b0feeae5464b9
Story: 2006832
Task: 37405
While not proper documentation, this should help people follow the ZTP
model.
Change-Id: If84a472826110bce151109ce80e70e1cef2a8177
Story: 2006640
Task: 37389
Kayobe has been using upstream kolla images by default since the Queens
release, as configured by the `kolla_docker_namespace` variable.
Change-Id: Ib56256abbadf0b5f22ef7780af2b9de63a8f157a
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
Ensure all references to the Ansible control host are worded as such, to
ensure consistency and avoid potential confusion with the OpenStack
controllers.
Change-Id: Id92e537ccbfdd55287b8eae296f649640c70ce17
The admin network is intended for remote admin access to
the overcloud hosts e.g SSH. If admin_oc_net_name is not set
it will default to provision_oc_net_name for backwards
compatability.
Story: 2002096
Task: 19774
Change-Id: Ib04bbc07f97218d7503000cc363624c60c287822
It is hard to know when disk images need to be rebuilt, and the
stackhpc.os-images role simply checks for the presence of the DIB output
directory to indicate that an image exists. In some cases, we may wish to force
the rebuilding of a deployment (IPA) image, when we know there are changes to
apply. This change adds a --force-rebuild argument to the following commands:
kayobe seed deployment image build
kayobe overcloud deployment image build
Change-Id: I580811a4f621df9445ef32773ca66bcf303dad9b
The version of cloud-init included with CentOS7.5 (0.7.9-24)
fails to assign an IP address on VLAN subinterfaces. This
workaround upgrades cloud-init to 18.2 using a private
repository.
Story: 2002610
Task: 22229
Change-Id: Idc570b9ca7558dfd42246c74b1ec0331011d692f
This add supports for running the stackhpc.grafana-conf Ansible
Galaxy role against a monitoring server to configure Grafana
post deployment. This includes:
* Creating an organisation
* Configuring dashboards for the organisation from a git repo
* Configuring datasources for the organisation
Allow the physical network interface configuration to be limited to a subset of
interfaces, either by interface name or switch interface description. This is done
via:
kayobe physical network configure --interface-limit interface1,interface2
or
kayobe physical network configure --interface-description-limit host1,host2
Fixes: #25
The CLI command is:
kayobe overcloud introspection data save [--output-dir <dir>] [--output-format <format>]
This command will save introspection data collected by the seed host's ironic
inspector service to the control host for analysis.
Overcloud deployment images can now be built via:
kayobe overcloud deployment image build
This should be done prior to running kayobe overcloud service deploy.
In order to build IPA images, the ipa_build_images variable should be
set to True. In this case, these images will be used by the overcloud's
ironic inspector service during hardware inspection, and by ironic
during provisioning.
The CLI command is:
kayobe seed deployment image build
This command will build Ironic Python Agent (IPA) kernel and ramdisk images
using the Diskimage Builder (DIB) ironic-agent element. The built images will
be copied to the appropriate location in the bifrost_deploy container on the
seed.
This allows us to build a customised image with site- or hardware- specific
extensions.
Ansible is now a dependency of kayobe, and should either be installed
in a virtualenv or in the site python packages, so we no longer need
to install it via yum.
Also stop running the kolla.yml playbook during control host bootstrap, as it
is now run when required.
Seunghun Lee