
It has been observed that, right after applying stx-openstack, an alarm
related to Ceph is being triggered by the platform due to pools not
being associated with the applications using them.
According the official documentation, [1] and [2], the pool/application
association is mandatory for Ceph releases equal to or greater than the
Luminous release (12.2.13).
In theory, this is already handled in openstack-helm's helm charts, such
as in Cinder's `storage-init` job [3]. One can even see that it only
performs the association for Ceph major versions >= 12, which matches
the official documentation's requirements.
However, the problem is that the code in [3] assumes that `ceph mgr
versions` will always report a numeric version, e.g.:
- `ceph version 14.2.15-2-g7407245e7b \
(7407245e7b329ac9d475f61e2cbf9f8c616505d6) nautilus (stable)`
The problem is that this is not always the case, especially after the
platform was migrated to Debian, which Ceph started to report:
- `ceph version Development (no_version) nautilus (stable)`
As a result, version checks like the one done in [3] are failing and
consequently pools are being created without the necessary associations.
Therefore, this change updates the storage init scripts for Cinder and
Glance to account for the scenario where a development version of Ceph
is used.
[1] https://docs.ceph.com/en/latest/rados/operations/pools/#create-a-pool
[2] https://docs.ceph.com/en/latest/rados/operations/pools/#associate-pool-to-application
[3] 7803000a54/cinder/templates/bin/_storage-init.sh.tpl (L32-L34)
Test Plan:
PASS - Build openstack-helm package
PASS - Build stx-openstack-helm-fluxcd package
PASS - Build stx-openstack helm charts
PASS - Upload/apply stx-openstack
PASS - Verify that Ceph is healthy
Closes-Bug: 2021887
Change-Id: I11291f220cb15fe616fc5e555c69f872254cf2c9
Signed-off-by: Luan Nunes Utimura <LuanNunes.Utimura@windriver.com>
This repo is for https://github.com/openstack/openstack-helm
Changes to this repo are needed for StarlingX and those changes are not yet merged. Rather than clone and diverge the repo, the repo is extracted at a particular git SHA, and patches are applied on top.
As those patches are merged, the SHA can be updated and the local patches removed.