Merge pull request #69824 from mohit84/backfill_stuck
crimson/osd: fix backfill deadlock in BackfillState::Waiting
BackfillState::Enqueuing unconditionally posts RequestWaiting{}
when budget available return false. Waiting can exit only via
ObjectPushed which requires an in-flight push. If the budget
is exhausted with no pushes in flight no objectPush will ever
arrive and the PG stalls permanently.
Solution: Introduce a dedicated BudgetBlocked state. When
budget_available() is false and tracked_objects_completed()==true
post RequestBudgetBlocked{} instead of RequestWaiting{}.
BudgetBlocked calls get_backfill_throttle() to suspend until a slots
free up, then fires BudgetAvailable{} which transitions directly back
to Enqueuing to dispatch the next batch of pushes.
ShreeJejurikar [Sat, 20 Jun 2026 10:58:49 +0000 (16:28 +0530)]
rgw: support kafka 4.x brokers
librdkafka submodule
Vendors librdkafka v2.12.1 as a submodule (default) and teaches the
notification teuthology task to set up Kafka 4.x KRaft brokers. The
distro-shipped librdkafka 1.6.1 cannot SCRAM-auth against Kafka 4.x
brokers (#75900); the bundled version fixes that. Build with
WITH_SYSTEM_RDKAFKA=ON to opt back into the distro library (floor 2.6.1).
follwinf changes needed with teh submodule:
* build kafka_stub only in case of system librdkafka
* use the same header location in submodule and system
* supress compilation warning to avoid -WError issues
2.12.1 matches Fedora(44)'s current librdkafka-devel, so the vendored copy
tracks a version that distro packagers have already vetted rather than
whichever release happens to be latest upstream.
The teuthology version matrix picks one of {3.9.2, 4.1, 4.2, 4.3} per run.
3.9.2 covers the last Zookeeper-based release for the migration cohort.
4.1/4.2/4.3 track Apache's current three supported minor lines and are
resolved to the latest patch at test time via dlcdn.apache.org/kafka/, so
new patches within a supported minor need no PR update. A new minor line
(4.4) requires renaming one YAML.
* new java version (17) is needed for kafka 4.2 and up (we wil use it on
all version)
* kerberos task need to run before the kafka install task
After pulling this branch, fetch the new submodule:
Nizamudeen A [Wed, 22 Jul 2026 06:29:36 +0000 (11:59 +0530)]
mgr/dashboard: replace gherkin-lint with prettier
I checked a couple of gherkin linters as an alternative but all of them
are not really well maintained. There are couple of new projeects but
even they are simply maintained by a single guy so i don't think it'll
get enough contributions later on. So instead, I am moving it to
prettier. Although we miss some functional validation, it'll take care
of some basic formatting.
Fixes: https://tracker.ceph.com/issues/78528 Signed-off-by: Nizamudeen A <nia@redhat.com>
script/ptl-tool: add unit tests for the credential fail-fast fix
Extract the Redmine auth check added in the previous commit into a
standalone verify_redmine_auth(R) function so it can be unit tested
in isolation, and add src/script/test_ptl_tool.py covering:
- verify_redmine_auth(): invalid key (AuthError), a key that
authenticates but lacks permission (ForbiddenError), a valid key,
and confirming unrelated Redmine errors (ServerError) still
propagate normally rather than being misreported as a credentials
problem.
- AuditReport.post_consolidated_review(): logs success on 2xx, logs
an error (rather than failing silently) on a non-2xx GitHub
response, never calls out to GitHub under --dry-run, and is a
no-op when the report has no issues to post.
No behavior change to verify_redmine_auth() itself -- this is a pure
extraction plus tests. ptl-tool.py has no existing test suite, so
these are self-contained (mocked Redmine/requests, no network access,
no real git checkout needed) and run with plain pytest; see the
module docstring for the exact invocation.
script/ptl-tool: fail fast and cleanly on invalid Redmine/GitHub credentials
Invalid credentials were handled inconsistently:
- A missing GitHub/Redmine token was caught with a clear error at
startup, but an invalid or expired one was not: the Redmine
client is constructed lazily by python-redmine, so a bad
~/.redmine_key was never actually exercised until
manage_qa_tracker() called R.project.get() -- which runs *after*
PRs have been merged and the integration branch/tag has already
been pushed to ceph-ci. The result was an unhandled traceback
well after real side effects had already happened, with no
actionable message.
- post_consolidated_review() posted the consolidated audit review
to GitHub without checking the response status at all, so a bad
or under-scoped token would fail silently there while every other
GitHub write call in the file already checks status_code.
Fix both:
- Immediately after constructing the Redmine client, make a cheap
R.user.get('current') call and catch AuthError/ForbiddenError,
exiting with a clear message before any merging or pushing
happens.
- Check the response status in post_consolidated_review() and log
an error on failure, matching the pattern already used by the
other GitHub POST call sites in this file.
Verified with py_compile plus live --dry-run runs against
tracker.ceph.com: a deliberately invalid PTL_TOOL_REDMINE_API_KEY
now exits 1 immediately with a clear message and no git side
effects, while a valid key proceeds exactly as before.
mgr/dashboard: set MOTD fails on FIPS enabled systems
Root cause: On FIPS-compliant systems, the OpenSSL provider rejects hashlib.md5() calls that lack the usedforsecurity=False flag, because MD5 is not an approved algorithm for security-sensitive use. This causes the MOTD set command — and the /api/motd create endpoint — to raise a ValueError and crash whenever a new MOTD is saved.
Fix: Pass usedforsecurity=False to hashlib.md5(). This tells the FIPS provider that MD5 is being used only as a non-cryptographic checksum (to detect whether a user has already dismissed a specific MOTD message), which is a legitimate use-case that FIPS allows.
mgr/DaemonServer: Make an ok-to-upgrade error message more generic
When no OSDs within a CRUSH bucket can be found to upgrade, the earlier error
message indicated the minimum number of PGs affected if any OSD was removed
from the set. For e.g.,
"Error EBUSY: unsafe to upgrade osd(s) at this time (at least X PG(s) will
become offline if any OSD out of the Y in CRUSH bucket 'foo' is stopped)"
This was inaccurate in some cases because the number of PGs affected is
determined only from the last tested OSD in the CRUSH bucket based on the sort
order (i.e., OSD with least number of PGs per OSD). Based on the CRUSH rules
and placement, this doesn't mean that the least number of PGs are affected if
this OSD is stopped. There may be other OSDs in the set that affect a smaller
number of PGs if made offline.
But with the way ok-to-upgrade logic uses the convergence factor, not all OSDs
would be tested for the offline pg check. Therefore, it is not possible to
accurately determine the minimum number affected PGs.
In view of the above, the error message is modified as shown below to be
slightly more generic but still convey the reason:
"Error EBUSY: unsafe to upgrade osd(s) at this time (one or more PG(s) will
become offline if any OSD out of the Y in CRUSH bucket 'foo' is stopped)"
python-common/rgw: fix get_realm_tokens returning empty result for realms with a secondary zone
Issue: The Export Multi-site Realm Token feature in the Dashboard showed no token and no realm details for any realm that had a secondary zone configured (i.e. the realm had been replicated to another cluster). The API endpoint GET /api/rgw/realm/get_realm_tokens returned an empty list or raised a 500 Internal Server Error.
ptl-tool: log the ceph-ci push (and the equivalent git command)
Previously, a real (non-dry-run) push of the integration branch/tag to
ceph-ci was silent -- only the "[DRY RUN] Would push ..." path logged
anything. Add matching log.info() calls on the real-push path, and
include the literal `git push <remote> <ref>` invocation in the message
so it can be copy-pasted and re-run manually if needed (e.g. after a
network blip, or to re-push without re-running the whole merge).
* refs/pull/52147/head:
PendingReleaseNotes: add an note about dmclock based scheduler for MDS
doc/config-ref: mention about MDS dmclock configurations
qa: use dmclock with fs:workload
mds: add MDS dmClock scheduler for subvolume QoS support
Reviewed-by: Venky Shankar <vshankar@redhat.com> Reviewed-by: Robin H. Johnson <robbat2@orbis-terrarum.net>
mgr/dashboard: exclude user scope from read-only system role
Read-only users could see the Settings icon but were denied access
to user management pages. Remove user read permission from the
read-only role so the administration menu stays hidden.
mgr/dashboard: allow read-only users to view Silences page
Remove SilenceFormComponent from the silences list page, which
incorrectly required create permission and caused a blank page for
users with prometheus read access only.
David Galloway [Fri, 17 Jul 2026 18:34:44 +0000 (14:34 -0400)]
container: default FROM_IMAGE to Rocky Linux 10
Since tentacle, the preferred base image for ceph containers has been
Rocky Linux 10, and the CI tag-naming logic in build.sh already assumes
rockylinux-10 is the default fromtag for every branch except reef and
squid. The actual build default was never flipped, though: anything
that ran build.sh without FROM_IMAGE set (e.g. the release container
job in ceph-build) still got a CentOS Stream 9 base.
Flip the Containerfile ARG and the build.sh fallback to
docker.io/rockylinux/rockylinux:10 so umbrella and later build from
Rocky 10 by default. Builds that want a different base can still pass
FROM_IMAGE explicitly, as the CI pipeline does.
Signed-off-by: David Galloway <david.galloway@ibm.com>
Aggressive Link-Time Optimization (LTO) and stricter linker defaults
in newer toolchains (like GCC 13 on Ubuntu 24.04) can strip or
localize external global variables if their visibility is not
explicitly defined. Tagging g_lockdep with default visibility ensures
it remains accessible in the dynamic symbol table for external
binaries like monmaptool.
Assisted-by: Gemini Fixes: https://tracker.ceph.com/issues/78321 Signed-off-by: Patrick Donnelly <pdonnell@ibm.com>