5843c6b04b gated the build on /etc/redhat-release because gRPC devel
libs weren't packaged on Debian yet. They are now (libgrpc++-dev,
protobuf-compiler-grpc), so we can finally bring Debian derivatives on
par with Fedora/RHEL and ship the NVMe-oF gateway monitor client there
too.
This change:
- drops the /etc/redhat-release sniff and unconditionally enables
WITH_NVMEOF_GATEWAY_MONITOR_CLIENT.
- adds libgrpc++-dev and protobuf-compiler-grpc to debian/control's
Build-Depends, plus a ceph-mon-client-nvmeof / -dbg pair so the
binary actually gets packaged.
- adds a pkg-config fallback for gRPC discovery. Jammy's libgrpc++-dev
(1.30.2) ships no cmake config files [1], so find_package(gRPC CONFIG
REQUIRED) fails at configure time. Noble's libgrpc++-dev (1.51.1)
does ship them [2], as do RHEL/Rocky packages. We now try cmake config
first (QUIET) and fall back to pkg_check_modules(IMPORTED_TARGET
grpc++) when it isn't found.
- patches PkgConfig::GRPCPP to carry protobuf::libprotobuf as an
interface dependency. grpc++.pc omits protobuf from its Requires, so
gateway.pb.cc (which calls GOOGLE_PROTOBUF_VERIFY_VERSION) would fail
to link on the pkg-config path. The cmake-config gRPC::grpc++ declares
this dependency properly; we match that behaviour with
target_link_libraries(PkgConfig::GRPCPP INTERFACE protobuf::libprotobuf).
- applies HAVE_ABSEIL only on the cmake-config path (Noble, RHEL/Rocky),
where gRPC links system absl. Without it, opentelemetry-cpp's private
absl (inline namespace otel_v1) collides with system absl (inline
namespace debian7) in any TU that includes both tracer.h and
grpcpp/grpcpp.h, giving "reference to base_internal is ambiguous".
On the pkg-config path (Jammy's gRPC 1.30.2) libabsl-dev is not
installed, so HAVE_ABSEIL must be skipped there.
[1] https://packages.ubuntu.com/jammy/amd64/libgrpc-dev/filelist
[2] https://packages.ubuntu.com/noble/amd64/libgrpc-dev/filelist
Signed-off-by: Kefu Chai <k.chai@proxmox.com>
Information regarding min_size in the EC Cluster Design doc was unclear in regards to the intention of what we want to develop. This commit is to clarify this so it is clear to readers.
Signed-off-by: Jon Bailey <jonathan.bailey1@ibm.com>
- Updated capacity used to show Raw capacity
- Pool table shows Raw capacity
- Total used capacity graph shows raw capacity
fixes: https://tracker.ceph.com/issues/76456
Signed-off-by: Ankush Behl <cloudbehl@gmail.com>
mgr/dashboard: "Access Denied" being shown on overview page for read-only user
Reviewed-by: Afreen Misbah <afreen@ibm.com>
Reviewed-by: Nizamudeen A <nia@redhat.com>
Tracker 75432 hits an assert which is attempting to protect the system
against hanging, due to generating a read request which sends no messages.
The assert fired because recovery was attempting to read multiple objects
in a single read request. One object did not require any further shard
reads in order to recover, while the other did. The consequence is that
the assert fired on one of the objects.
The problem is simply that the assert is in the wrong place.
Fixes: https://tracker.ceph.com/issues/75432
Signed-off-by: Alex Ainscow <aainscow@uk.ibm.com>
osd: PGLog Attach correct version to missing list when ignoring log entries
Reviewed-by: Bill Scales <bill_scales@uk.ibm.com>
Reviewed-by: Radoslaw Zarzynski <rzarzyns@redhat.com>
This commit removes centos9 from crimson's supported distros. This is in
line with the wider ceph moving on to rocky10 from centos9. We have
established that crimson is compatible with rocky10. More details can be
found in this tracker: https://tracker.ceph.com/issues/75823.
Signed-off-by: Shraddha Agrawal <shraddha.agrawal000@gmail.com>
Classic OSD enforces mutual exclusion between scrubbing and snap
trimming via the WaitScrub state in the snap trim state machine.
Crimson was missing this, allowing both to run concurrently on the
same PG (visible as active+clean+scrubbing+deep+snaptrim), which
could prevent snap trimming from completing within the expected
timeout.
Defer snap trim initiation while PG_STATE_SCRUBBING is set, and
re-trigger it from notify_scrub_end() via kick_snap_trim().
This is a temporary fix until the full scrub scheduling code,
including is_scrub_queued_or_active(), is merged.
Signed-off-by: Ronen Friedman <rfriedma@redhat.com>
by falling back to add_oid() instead of silently creating an
inconsistent state (OBJ_ without matching SNA_ entries). This
was observed on replicas that had recently recovered objects:
the snap mapper entries created during recovery were not visible
to a subsequent snap-trim repop's update_snaps() call, leaving
the clone with no snap mapper entries. Scrub would then detect
and report the inconsistency as an error.
Promote snap mapper remove_oid/clear_snaps logging to dout(10)
and add apply_op_stats tracing to aid diagnosis of any remaining
stat or snap mapper drift.
Signed-off-by: Ronen Friedman <rfriedma@redhat.com>
Add --logging-type flag to run the Python bucket logging test suite
in either Standard or Journal mode. The same tests run against both
logging types with no changes to test logic or assertions.
- Add --logging-type pytest CLI option (Standard default, Journal opt-in)
- Detect boto3 LoggingType extension availability at session startup
- Thread logging_type through helpers and test functions
- Add teuthology task YAML for Journal mode suite runs
- Install service-2.sdk-extras.json in the teuthology task when
logging_type is Journal (s3tests cleans it up after its own run,
so the file isn't available by the time our Journal job runs)
- Document Journal mode local usage in the test suite README
Signed-off-by: Shree Jejurikar <shree.jejurikar@gmail.com>
The LibRadosAio.PoolEIOFlag test was unstable, skip due to:
- Test Unreliability (Timing Dependency): The test used a fixed
iteration count for IO submission and finished too quickly, missing the
target error.
* Fix: The submission loop now runs continuously (time-bounded)
until the EIO error is reliably caught, eliminating the timing issue.
Fixes: https://tracker.ceph.com/issues/73946
Signed-off-by: Nitzan Mordechai <nmordec@ibm.com>
The LibRadosAio.PoolEIOFlag test was unstable, it was hanging due to:
- Deadlock: The main thread held the shared mutex ('my_lock') while
calling thread join. This created a mutual deadlock.
* Fix: Mutex is unlocked before thread join using RAII scopes.
- also convert to std::jthread and drop the join
Fixes: https://tracker.ceph.com/issues/73946
Signed-off-by: Nitzan Mordechai <nmordec@ibm.com>
