CLOS-6809: compare Governor DB versions numerically, not by spelling - #71
Open
prilr wants to merge 4 commits into
Open
CLOS-6809: compare Governor DB versions numerically, not by spelling#71prilr wants to merge 4 commits into
prilr wants to merge 4 commits into
Conversation
A Governor-managed MariaDB 11.4 system could not be upgraded at all: leapp
inhibited with "cl-mysql.repo does not match the installed database type",
naming an expected repository path of cl-mariadb-11.4 that does not exist.
The ticket describes this as a deadlock between two checks. It is one defect.
Governor derives the token it caches in mysql.type.installed with exactly the
expression leapp uses in get_clmysql_version_from_pkg():
"%s%s" % (name, "".join(version.split(".")[:2])) # 11.4.12 -> mariadb114
Both sides therefore agree on an untouched system and the "Mismatch between
Governor DB type and installed packages" inhibitor cannot fire; it appears only
after a customer follows KCS 27757797511068 and hand-writes mariadb1104 into the
file. The single real bug is that leapp then predicted the repository directory
from that token. Governor's spelling is a hand-maintained table, not an
algorithm: MariaDB 11.4 is published as cl-mariadb-11.04 (minor padded to two
digits) while 10.6 is cl-mariadb-10.6 (not padded), so the prediction produced a
phantom cl-mariadb-11.4.
Verified against repo.cloudlinux.com on 2026-08-05 - cl-mariadb-11.04 and
cl-mariadb-11.08 return 200 for both cl8 and cl9, cl-mariadb-11.4 and
cl-mariadb-11.8 return 404 - so no edit of cl-mysql.repo could satisfy the check
either, and the remediation hint leapp printed pointed at a 404.
Rather than mirror Governor's table here, parse both sides to a numeric
(family, major, minor) triple and compare that. The two spellings collapse onto
the same triple - mariadb114 and mariadb1104 are both ("mariadb", 11, 4) - so
the check needs no knowledge of how Governor spelled anything, and a future
series cannot silently reintroduce this bug by being absent from a table. The
same applies to the repository URL: cl-mariadb-11.04 and a hypothetical
cl-mariadb-11.4 both parse to the same version. A mirrored table was tried first
and rejected for exactly this reason - it is correct only until Governor adds a
series with a single-digit minor under a two-digit major, and then fails the
same way, silently.
MODULE_STREAMS stays, because the DNF module stream name is built from Governor's
spelling (cl-MariaDB1104) and cannot be derived; it is also pre-existing and
already reports when it has to guess. canonical_clmysql_type() consults it as the
registry of confirmed streams rather than adding a second table. No mariadb1108
entry is added: Governor declares mariadb:cl-MariaDB1108, but the published
cl-mariadb-11.08 repository carries no modules.yaml on cl8 or cl9 and
`dnf module list` against it returns nothing, so that stream cannot be confirmed
to exist. Leaving it out keeps the "module stream was derived automatically"
report, which is the signal we want until that content question is settled.
The URL remediation no longer names a repository file to download. Predicting
that filename is what produced the 404 in this ticket, and re-running
`mysqlgovernor.py --install --yes` regenerates cl-mysql.repo correctly by
definition. The report now states both versions - the installed one and the one
the repository describes - instead of a path the customer cannot fetch.
Validated on a CL8.10 VM with the reporter's package set (governor-mysql-1.2-147,
cl-MariaDB1104-11.4.12, leapp-upgrade-el8toel9-0.20.0-9): reproduced on stock
packages with no manual edits, hitting the same report key
c38e8f2dbe0f7a618685d87e692f6206868f9393 and the same 404 hint. Afterwards
leapp preupgrade reaches RC=0 with no inhibitors and no errors, produces target
repo cl-mysql-meta-9 -> .../cl9/mysqlmeta/cl-mariadb-11.04/$basearch/, enables
mariadb:cl-MariaDB1104, and the CL9 dnf transaction check resolves. Note that
leapp skips TargetTransactionCheck entirely while any inhibitor remains, so
clearing the DB-type inhibitor alone would not have proven the transaction.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
prilr
force-pushed
the
CLOS-6809-mariadb-11-4-governor-db-token
branch
from
August 11, 2026 13:47
54779e8 to
313f731
Compare
… repository
With the version check no longer predicting Governor's spelling, one place still
had to know it: the DNF module stream name is built from the token
("mariadb1104" -> "cl-MariaDB1104"), and MODULE_STREAMS only lists the streams we
have confirmed. For anything absent from that table the code fell back to
deriving the name from the type token, which Governor caches with the minor
version's leading zero dropped. A future MariaDB 12.4 would therefore have
enabled cl-MariaDB124 where the real stream is cl-MariaDB1204.
That failure is quieter than the one this branch started from: it is a MEDIUM
report rather than an inhibitor, so the upgrade proceeds and only fails later,
when DNF cannot enable a module that does not exist.
The cl-mysql-meta repository directory carries the same digits as the stream
name, padding included, so read it from there instead: cl-mariadb-11.04 goes with
cl-MariaDB1104 and cl-mariadb-10.6 with cl-MariaDB106. Checked against every
(repo directory, module stream) pair in governor-mysql 1.2-147 - all 17 reproduce
exactly - plus both shapes a future 12.x could take.
Order of preference is unchanged where it matters: MODULE_STREAMS still wins,
because it records streams that were actually verified to exist; the repository
is consulted only for a series that table does not cover; and the token-derived
guess remains as a last resort for a system with no usable repository. Reading
the repository is safe at this point because clmysql_process() has already
inhibited the upgrade if it does not describe the installed database - only a
confirmed baseurl is stored on the shared library object.
A side effect worth noting: MariaDB 11.8 now resolves to cl-MariaDB1108 rather
than the phantom cl-MariaDB118, while still carrying the "module stream was
derived automatically" report, since whether that module is published at all is
still open.
Validated on the CL8.10 VM: leapp preupgrade still reaches RC=0 with no
inhibitors or errors, and MariaDB 11.4 still resolves through MODULE_STREAMS to
mariadb:cl-MariaDB1104 with the same target repository as before.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
prilr
force-pushed
the
CLOS-6809-mariadb-11-4-governor-db-token
branch
from
August 12, 2026 11:45
313f731 to
4c1d3b8
Compare
prilr
changed the title
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
A Governor-managed MariaDB 11.4 system could not be upgraded at all: leapp inhibited with "cl-mysql.repo does not match the installed database type", naming an expected repository path of
cl-mariadb-11.4that does not exist.The original issue describes this as a deadlock between two checks. That's not quite correct.
Governor derives the token it caches in mysql.type.installed with exactly the expression leapp uses in
get_clmysql_version_from_pkg():Both sides therefore agree on an untouched system and the "Mismatch between Governor DB type and installed packages" inhibitor cannot fire.
It appears only after a customer follows a remediation hint and hand-writes
mariadb1104into the file. The single real bug is thatmariadb114is not the canonical token. Governor acceptsmariadb1104on--mysql-version, names the DNF module streamcl-MariaDB1104and publishes the repository ascl-mariadb-11.04.The spelling comes from
MySQLManager.REPO_NAMES, a hand-maintained table rather than an algorithm: the 11.x series pads the minor version to two digits, 10.x does not.Verified against repo.cloudlinux.com on 2026-08-05 -
cl-mariadb-11.04andcl-mariadb-11.08return 200 for both cl8 and cl9,cl-mariadb-11.4andcl-mariadb-11.8return 404 - so no edit ofcl-mysql.repocan satisfy the check either, and the remediation hint leapp printed pointed at a 404.Solution: Mirror Governor's table as
CLMYSQL_REPO_NAMESand normalize the lossy token onto the canonical one at both detection points. Tokens that are already canonical, and unknown ones, pass through untouched so a future DB series keeps today's best-effort handling instead of being rewritten into something that does not exist.No
mariadb1108entry is added toMODULE_STREAMSon purpose. Governor declaresmariadb:cl-MariaDB1108, but the publishedcl-mariadb-11.08repository carries no modules.yaml on either cl8 or cl9, anddnf module listagainst it returns no module - unlikecl-mariadb-11.04, which does contribute thecl-MariaDB1104stream. Leaving it out keeps the "module stream was derived automatically" report, which is the signal we want to keep.Validated with the reporter's package set (
governor-mysql-1.2-147,cl-MariaDB1104-11.4.12,leapp-upgrade-el8toel9-0.20.0-9): reproduced on stock packages with no manual edits, hitting the same report key and the same 404 hint.After the change leapp preupgrade reaches RC=0 with no inhibitors, produces target repo
cl-mysql-meta-9->.../cl9/mysqlmeta/cl-mariadb-11.04/$basearch/, enablesmariadb:cl-MariaDB1104, and the CL9 dnf transaction check resolves.The eight new library cases and two of the three new actor cases fail against 0.20.0-9 and pass afterwards with no test edits; the third case, a genuinely mismatched repofile, passes both before and after, confirming the guard still inhibits what it should.