We use that variable in Kolla in many places. There are places in
'kolla-ansible' where we also need it.
Change-Id: Iea78c4a7cb0fd1405ea7299cdcf0841f63820c8c
The RabbitMQ role supports namespacing the service via the
project_name. For example, if you change the project_name, the
container name and config directory will be renamed accordingly. However
the log folder is currently fixed, even though the service tries to
write to one named after the project_name. This change fixes that.
Whilst you might generally use vhosts, running multiple RabbitMQ
services on a single node is useful at the very least for testing,
or for running 'outward RabbitMQ' on the same node.
This change is part of the work to support Cells v2.
Partially Implements: blueprint support-nova-cells
Change-Id: Ied2c24c01571327ea532ba0aaf2fc5e89de8e1fb
- add support for sha256 in bslurp module
- change sha1 to sha256 in ceph-mon ansible role
Depends-On: https://review.opendev.org/655623
Change-Id: I25e28d150f2a8d4a7f87bb119d9fb1c46cfe926f
Closes-Bug: #1826327
According to Docker upstream release notes [1] MountFlags should be
empty.
1. https://docs.docker.com/engine/release-notes/#18091
"Important notes about this release
In Docker versions prior to 18.09, containerd was managed by the Docker
engine daemon. In Docker Engine 18.09, containerd is managed by systemd.
Since containerd is managed by systemd, any custom configuration to the
docker.service systemd configuration which changes mount settings (for
example, MountFlags=slave) breaks interactions between the Docker Engine
daemon and containerd, and you will not be able to start containers.
Run the following command to get the current value of the MountFlags
property for the docker.service:
sudo systemctl show --property=MountFlags docker.service
MountFlags=
Update your configuration if this command prints a non-empty value for
MountFlags, and restart the docker service."
Closes-bug: #1833835
Change-Id: I4f4cbb09df752d00073a606463c62f0a6ca6c067
In the current deployment of ceph, the node name of osd and the name
of mon are both IP, and other daemons use hostname.
This commit adds support for naming mon and osd nodes using hostname,
and does not change the default ip-named way.
Change-Id: I22bef72dcd8fc8bcd391ae30e4643520250fd556
1) ceph-nfs (ganesha-ceph) - use NFSv4 only
This is recommended upstream.
v3 and UDP require portmapper (aka rpcbind) which we
do not want, except where Ubuntu ganesha version (2.6)
forces it by requiring enabled UDP, see [1].
The issue has been fixed in 2.8, included in CentOS.
Additionally disable v3 helper protocols and kerberos
to avoid meaningless warnings.
2) ceph-nfs (ganesha-ceph) - do not export host dbus
It is not in use. This avoids the temptation to try
handling it on host.
3) Properly handle ceph services deploy and upgrade
Upgrade runs deploy.
The order has been corrected - nfs goes after mds.
Additionally upgrade takes care of rgw for keystone
(for swift emulation).
4) Enhance ceph keyring module with error detection
Now it does not blindly try to create a keyring after
any failure. This used to hide real issue.
5) Retry ceph admin keyring update until cluster works
Reordering deployment caused issue with ceph cluster not being
fully operational before taking actions on it.
6) CI: Remove osd df from collected logs as it may hang CI
Hangs are caused by healthy MON and no healthy MGR.
A descriptive note is left in its place.
7) CI: Add 5s timeout to ceph informational commands
This decreases the timeout from the default 300s.
[1] https://review.opendev.org/669315
Change-Id: I1cf0ad10b80552f503898e723f0c4bd00a38f143
Signed-off-by: Radosław Piliszek <radoslaw.piliszek@gmail.com>
We often specific the project name after "{{ node_config_directory }}",
for example,
``{{ node_config_directory }}/cinder-api/:{{ container_config_directory }}/:ro``.
As the "{{ project }}" option is not configured, This line was
generated with:
``/etc/kolla//cinder-api/:...``
There would be double slash exists. It's OK, but confusing.
Change-Id: I82e6a91b2c541e38cf8e97896842149b31244688
Closes-Bug: #1838259
This actually replaces two ad-hoc fixes with a more unified
solution (with comment for posterity).
Change-Id: I62f57cb489c900f68a0c7aeb3e20e4715c0e2661
Signed-off-by: Radosław Piliszek <radoslaw.piliszek@gmail.com>
Multinode jobs did not run sanity checks for all the hosts,
only primary. Now they check all.
Additionally upgrades are now checked using the proper
(pre-upgrade) scripts (not that it matters too much as they
are the same atm) and both checks are done, not only failures,
but also config.
Change-Id: I10552e256edbddd5b1f8a8a7f8805262e72ce8d8
Signed-off-by: Radosław Piliszek <radoslaw.piliszek@gmail.com>
Neutron FWaaS v1 is deprecated and removed since stein cycle by [0]. So
remove related options in kolla.
[0] https://review.opendev.org/616410
Change-Id: Ia03e7979dd48bafb34c11edd08c2a2a87b949e0e
Most other services already gate the DB bootstrap operations with the
'use_preconfigured_databases' variable; Blazar did not.
Change-Id: I772b1cb92612c7e6936f052ed9947f93582f264c
For deployments with a lot of Gnocchi data, this is a non-starter
(literally... the service basically can't start.) There maybe needs to
be a way to configure this, or only do it during deploy/bootstrap?
Unclear, but disabling for now; users can `chown -R gnocchi:gnocchi`
themselves in the meantime if need be.
Change-Id: I0bae6dfbbee9f63506c89bd6b392e7be07fd5930
Change https://review.opendev.org/#/c/670247/ attempted to fix glance
deployment with the file backend. However, it added a new bug by being
more strict about only generating configuration where the container will
be deployed. This means that the current method of running the glance
bootstrap container on any host in glance-api group could be broken,
since it needs the container configuration.
This change only runs the bootstrap container on hosts in the
glance_api_hosts list, which in the case of the file backend typically
only contains one host.
This change also fixes up some logic during rolling upgrade, where we
might not generate new configuration for the bootstrap host.
Change-Id: I83547cd83b06ddefb3a9e1f39844537bdb32bd7f
Related-Bug: #1836151
Docker has no restart policy named 'never'. It has 'no'.
This has bitten us already (see [1]) and might bite us again whenever
we want to change the restart policy to 'no'.
This patch makes our docker integration honor all valid restart policies
and only valid restart policies.
All relevant docker restart policy usages are patched as well.
I added some FIXMEs around which are relevant to kolla-ansible docker
integration. They are not fixed in here to not alter behavior.
[1] https://review.opendev.org/667363
Change-Id: I1c9764fb9bbda08a71186091aced67433ad4e3d6
Signed-off-by: Radosław Piliszek <radoslaw.piliszek@gmail.com>
The keepalived_virtual_router_id should be changed from the default in
the case of a multi-region deployment where the VIP of the different
regions resides on the same subnet.
This is not immediately clear - this change should make it more obvious.
Change-Id: Ia4899ba407937d9f27832c9d123701729e89987a
We install kolla-ansible requirements in Zuul's Ansible playbooks.
This patch cleans up the installation in scripts so that they are
only concerned with auxiliary requirements:
- ansible (since we do not track it in requirements)
- ara (for log summaries)
- openstack clients (for first init and tests after deployment)
Additionally this patch installs openstack clients in a separate
virtualenv.
Note that all kolla-ansible requirements, ansible and ara are still
installed system-wide.
Change-Id: Iac04082ad39a9d823c515ba11c5db9af50ed225f
Signed-off-by: Radosław Piliszek <radoslaw.piliszek@gmail.com>
* Ubuntu ships with nfs-ganesha 2.6.0, which requires to do an rpcbind
udp test on startup (was fixed later)
* Add rpcbind package to be installed by kolla-ansible bootstrap when
ceph_nfs is enabled
* Update Ceph deployment docs with a note
Change-Id: Ic19264191a0ed418fa959fdc122cef543446fbe5
The ironic inspector iPXE configuration includes the following kernel
argument:
initrd=agent.ramdisk
However, the ramdisk is actually called ironic-agent.initramfs, so the
argument should be:
initrd=ironic-agent.initramfs
In BIOS boot mode this does not cause a problem, but for compute nodes
with UEFI enabled, it seems to be more strict about this, and fails to
boot.
Change-Id: Ic84f3b79fdd3cd1730ca2fb79c11c7a4e4d824de
Closes-Bug: #1836375
