ceph.spec.in: Include Crimson by default by Matan-B · Pull Request #66229 · ceph/ceph

Matan-B · 2025-11-13T10:45:26Z

With #65782 merged, Crimson could be now built as part of the default RPM build flavor. The binaries ceph-osd-crimson and ceph-osd-classic are managed via update-alternatives and selected based on priority:

ceph-osd-classic keeps the highest priority (100) and remains the default.
Switching to crimson is possible via: update-alternatives --set ceph-osd /usr/bin/ceph-osd-crimson

Existing classic behavior remains unchanged unless the above command is explicitly executed.

Related work:

Followups:

CI pipline to stop building Crimson dedicated builds -> build flavors: Cleanup "crimson", introduce "debug" ceph-build#2497
Update containerized/orch usage -> https://tracker.ceph.com/issues/73970
Enable WITH_CRIMSON in cmake by default
Documentation

Contribution Guidelines

To sign and title your commits, please refer to Submitting Patches to Ceph.
If you are submitting a fix for a stable branch (e.g. "quincy"), please refer to Submitting Patches to Ceph - Backports for the proper workflow.
When filling out the below checklist, you may click boxes directly in the GitHub web UI. When entering or editing the entire PR message in the GitHub web UI editor, you may also select a checklist item by adding an x between the brackets: [x]. Spaces and capitalization matter when checking off items this way.

Checklist

Tracker (select at least one)
- References tracker ticket
- Very recent bug; references commit where it was introduced
- New feature (ticket optional)
- Doc update (no ticket needed)
- Code cleanup (no ticket needed)
Component impact
- Affects Dashboard, opened tracker ticket
- Affects Orchestrator, opened tracker ticket
- No impact that needs to be tracked
Documentation (select at least one)
- Updates relevant documentation
- No doc update is appropriate
Tests (select at least one)
- Includes unit test(s)
- Includes integration test(s)
- Includes bug reproducer
- No tests

Show available Jenkins commands

jenkins test classic perf Jenkins Job | Jenkins Job Definition
jenkins test crimson perf Jenkins Job | Jenkins Job Definition
jenkins test signed Jenkins Job | Jenkins Job Definition
jenkins test make check Jenkins Job | Jenkins Job Definition
jenkins test make check arm64 Jenkins Job | Jenkins Job Definition
jenkins test submodules Jenkins Job | Jenkins Job Definition
jenkins test dashboard Jenkins Job | Jenkins Job Definition
jenkins test dashboard cephadm Jenkins Job | Jenkins Job Definition
jenkins test api Jenkins Job | Jenkins Job Definition
jenkins test docs ReadTheDocs | Github Workflow Definition
jenkins test ceph-volume all Jenkins Jobs | Jenkins Jobs Definition
jenkins test windows Jenkins Job | Jenkins Job Definition
jenkins test rook e2e Jenkins Job | Jenkins Job Definition

You must only issue one Jenkins command per-comment. Jenkins does not understand
comments with more than one command.

Matan-B · 2025-11-13T10:49:37Z

jenkins test api

CMakeLists.txt

Matan-B · 2025-11-17T10:18:26Z

https://shaman.ceph.com/builds/ceph/wip-matanb-crimson-on-v2/f2bc535c03ce9df89c0be33985e8ac99def50ecc/

Matan-B · 2025-11-17T12:34:27Z

jenkins test api

tchaikov · 2025-11-17T13:48:54Z

CMakeLists.txt

+find_program(RPM_EXECUTABLE rpm)
+if(RPM_EXECUTABLE)
+  set(WITH_CRIMSON ON)
+endif()


i am not in favor of this change. the existing of rpm executable should not be connected with the "RPM build flavor", or whatever it implies.

and we should not override the user setting, what if a user explicitly specifies WITH_CRIMSON=OFF ?

we should enable/disable WITH_CRIMSON at a higher level -- or, we could provide a default value after detecting its dependencies. like:

option(WITH_CRIMSON "Build Crimson components" ALL_DEPS_BUILDING_CRIMSON_FULFILLED)

just read the thread at #66229 (comment) . i still think we should detect the deps properly instead of wiring this option with "rpm". please note, one can install "rpm" on a debian derivative distro.. it's another counter proof that the existing of "rpm" does not serve as a signal that the system is capable of building crimson.

if we aren't ready to enable this by default, maybe we should just leave it as-is. rpm builds will enable it due to the change to ceph.spec.in, 'make check' enables it for pull requests, and developers still need to enable manually

if we aren't ready to enable this by default, maybe we should just leave it as-is. rpm builds will enable it due to the change to ceph.spec.in, 'make check' enables it for pull requests, and developers still need to enable manually

Seems reasonable, we can start with changing our spec.in and followup with a proper (ALL_DEPS_BUILDING_CRIMSON_FULFILLED) cmake later on.

I've updated the PR to drop the CMake changes for now.

ceph.spec.in

qa/suites/rados/thrash-old-clients/1-install/reef.yaml

qa/crontab/teuthology-cronjobs

Matan-B · 2025-11-19T09:36:39Z

Testing default flavor (https://shaman.ceph.com/builds/ceph/wip-matanb-crimson-on/d875ca0c686188a797e829db2d9df14d402836bb/default/):

-s rados:
https://pulpito.ceph.com/matan-2025-11-19_09:16:47-rados-wip-matanb-crimson-on-distro-default-smithi/
-s crimson-rados:
https://pulpito.ceph.com/matan-2025-11-19_09:35:22-crimson-rados-wip-matanb-crimson-on-distro-default-smithi/

With ceph#65782 merged, Crimson could be now built as part of the default RPM build flavor. The binaries ceph-osd-crimson and ceph-osd-classic are managed via `update-alternatives` and selected based on priority: - ceph-osd-classic keeps the **highest** priority (100) and remains the default. - Switching to crimson is possible via: update-alternatives --set ceph-osd /usr/bin/ceph-osd-crimson Existing classic behavior remains unchanged unless the above command is explicitly executed. Signed-off-by: Matan Breizman <mbreizma@redhat.com>

In an attempt to use the default flavor for both crimson and classic, we can no longer rely on flavors to enable crimson flags. The existing CRIMSON_COMPAT env variable is defined under "workunit", and is not supported by tasks/ceph. Instead, introduce, a dedicated crimson_compat option supported by tasks/ceph. Signed-off-by: Matan Breizman <mbreizma@redhat.com>

a37b5b5 added ceph-osd-crimson as dependency using OR requirement. Once ceph-osd-classic dependency is satisfied, ceph-osd-crimson package must be added manually. In order to not add crimson packages manually (See "Containerfile" removed lines) - mark osd-crimson as dependency if with_crimson is enabled for rpm and if pkg.ceph.crimson build profile is enabled for debian. With this change, users won't be required to obtain ceph-osd-crimson package manually when relevant. Similarly to ceph-osd-classic being a dependency for ceph-osd. Signed-off-by: Matan Breizman <mbreizma@redhat.com>

By enabling crimson in the "default" flavor - we should be able to cleanup "crimson-release" flavor. Update the cronjob ro use the default build flavor. Signed-off-by: Matan Breizman <mbreizma@redhat.com>

Similarly to ceph#66268. Once crimson is enabled in RPM, ceph-osd-crimson will be requried as a dependency. old-clients and upgrade tests should not try to install the new package as it is not available in older releases. See: https://tracker.ceph.com/issues/73848 Signed-off-by: Matan Breizman <mbreizma@redhat.com>

Matan-B · 2025-11-19T14:22:46Z

Note: ceph/teuthology#2110 can help when looking at teuthology logs

With ceph/ceph#66229 merged, Crimson is now included (though not used) by default in our RPM builds. This means the existing default flavor can also be used for Crimson testing by selecting Crimson as the default OSD package. Notes: * The previous workaround related to DWITH_STATIC_LIBSTDCXX is no longer relevant for Crimson (it was tied to older compiler issues). * The crimson-only branch name selection is also cleaned up, as centos9-only can now be used instead. * This change breaks Crimson Tentacle CI builds: The packaging update that includes Crimson in RPM builds was not backported to Tentacle. Tentacle builds would still require a dedicated flavor that enables WITH_CRIMSON However, since Crimson changes have not been backported to Tentacle (since the first RCA), there is no strong reason to keep building and testing the same Crimson HEAD. So we can use this opprtuinity to stop nightly Crimson/Tentacle builds and tests. See last Crimson tentacle run, (which is not expected to change): https://pulpito.ceph.com/teuthology-2025-11-22_22:56:11-crimson-rados-tentacle-distro-crimson-debug-smithi/ Signed-off-by: Matan Breizman <mbreizma@redhat.com>

…uilds. So if we're trying > to build with crimson disabled, the bcond must be reversed. Signed-off-by: T K Chandra Hasan <t.k.chandra.hasan@ibm.com>

…lds. So if we're trying to build with crimson disabled, the bcond must be reversed. Signed-off-by: T K Chandra Hasan <t.k.chandra.hasan@ibm.com>

With ceph#66229 merged, crimson is now enabled by default for RPM builds. So if we're trying to build with crimson disabled, the bcond must be reversed. Signed-off-by: T K Chandra Hasan <t.k.chandra.hasan@ibm.com>

With ceph#66229 merged, crimson is now enabled by default for all the builds. So if we're trying to build with crimson disabled, the bcond must be reversed to install the relavant dependencies. Signed-off-by: T K Chandra Hasan <t.k.chandra.hasan@ibm.com>

With ceph/ceph#66229 merged, Crimson is now included (though not used) by default in our RPM builds. This means the existing default flavor can also be used for Crimson testing by selecting Crimson as the default OSD package. Notes: * The previous workaround related to DWITH_STATIC_LIBSTDCXX is no longer relevant for Crimson (it was tied to older compiler issues). * The crimson-only branch name selection is also cleaned up, as centos9-only can now be used instead. * This change breaks Crimson Tentacle CI builds: The packaging update that includes Crimson in RPM builds was not backported to Tentacle. Tentacle builds would still require a dedicated flavor that enables WITH_CRIMSON However, since Crimson changes have not been backported to Tentacle (since the first RCA), there is no strong reason to keep building and testing the same Crimson HEAD. So we can use this opprtuinity to stop nightly Crimson/Tentacle builds and tests. See last Crimson tentacle run, (which is not expected to change): https://pulpito.ceph.com/teuthology-2025-11-22_22:56:11-crimson-rados-tentacle-distro-crimson-debug-smithi/ Signed-off-by: Matan Breizman <mbreizma@redhat.com>

With ceph#66229 merged, crimson is now enabled by default for all the builds. So if we're trying to build with crimson disabled, the bcond must be reversed to install the relavant dependencies. Signed-off-by: T K Chandra Hasan <t.k.chandra.hasan@ibm.com>

github-actions bot added the build/ops label Nov 13, 2025

Matan-B mentioned this pull request Nov 13, 2025

[WIP] Include Crimson binary by default (Centos) ceph/ceph-build#2493

Closed

Matan-B added this to Crimson Nov 13, 2025

Matan-B moved this to Unassigned / Drafts / Discussion in Crimson Nov 13, 2025

Matan-B added the pending-discussion label Nov 13, 2025

Matan-B requested review from a team, athanatos, cbodley, rzarzynski and tchaikov November 13, 2025 10:47

Matan-B requested a review from jdurgin November 13, 2025 10:50

cbodley reviewed Nov 13, 2025

View reviewed changes

CMakeLists.txt Outdated Show resolved Hide resolved

Matan-B requested a review from cbodley November 13, 2025 15:27

cbodley approved these changes Nov 13, 2025

View reviewed changes

Matan-B force-pushed the wip-matanb-crimson-on branch 2 times, most recently from 0b6c3ea to 54948f4 Compare November 16, 2025 10:44

This was referenced Nov 16, 2025

debian,ceph.spec: add ceph-osd-crimson as dependency #66267

Closed

qa/suites/thrash-old-clients/1-install: exclude ceph-osd-classic #66268

Merged

github-actions bot added the tests label Nov 16, 2025

Matan-B force-pushed the wip-matanb-crimson-on branch from 058057d to e15f136 Compare November 17, 2025 09:02

github-actions bot added the core label Nov 17, 2025

Matan-B force-pushed the wip-matanb-crimson-on branch from dde16b5 to eea322a Compare November 17, 2025 10:09

tchaikov reviewed Nov 17, 2025

View reviewed changes

Matan-B force-pushed the wip-matanb-crimson-on branch 2 times, most recently from 63b567a to d875ca0 Compare November 18, 2025 08:56

Matan-B moved this from Unassigned / Drafts / Discussion to Awaits review in Crimson Nov 18, 2025

Matan-B marked this pull request as ready for review November 18, 2025 08:57

Matan-B requested a review from a team as a code owner November 18, 2025 08:57

Matan-B requested a review from tchaikov November 18, 2025 08:57

Matan-B added the wip-matan-testing label Nov 19, 2025

Matan-B force-pushed the wip-matanb-crimson-on branch from d875ca0 to 304e806 Compare November 19, 2025 13:10

Matan-B changed the title ~~CMakeLists: Include Crimson by default in RPM builds~~ ceph.spec.in: Include Crimson by default Nov 19, 2025

Matan-B added 5 commits November 19, 2025 13:14

qa/crontab/teuthology-crontab: use default flavor for crimson

a639ca7

By enabling crimson in the "default" flavor - we should be able to cleanup "crimson-release" flavor. Update the cronjob ro use the default build flavor. Signed-off-by: Matan Breizman <mbreizma@redhat.com>

Matan-B force-pushed the wip-matanb-crimson-on branch from 304e806 to 807b32e Compare November 19, 2025 13:14

Matan-B added the TESTED label Nov 19, 2025

Matan-B removed the pending-discussion label Nov 20, 2025

cbodley approved these changes Nov 20, 2025

View reviewed changes

Matan-B merged commit 9c048a9 into ceph:main Nov 20, 2025
16 checks passed

Matan-B moved this from Awaits review to Merged (Main) in Crimson Nov 20, 2025

Matan-B mentioned this pull request Nov 23, 2025

qa/suites/rados/encoder: exclude ceph-osd-classic when installing LTS… #66372

Merged

14 tasks

Matan-B mentioned this pull request Nov 23, 2025

build flavors: Cleanup "crimson", introduce "debug" ceph/ceph-build#2497

Merged

hasan4791 mentioned this pull request Nov 27, 2025

Fix install-deps.sh script when crimson flag is disabled #66441

Merged

14 tasks

Conversation

Matan-B commented Nov 13, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Contribution Guidelines

Checklist

Uh oh!

Matan-B commented Nov 13, 2025

Uh oh!

Uh oh!

Matan-B commented Nov 17, 2025

Uh oh!

Matan-B commented Nov 17, 2025

Uh oh!

tchaikov Nov 17, 2025

Choose a reason for hiding this comment

Uh oh!

tchaikov Nov 17, 2025

Choose a reason for hiding this comment

Uh oh!

cbodley Nov 17, 2025

Choose a reason for hiding this comment

Uh oh!

Matan-B Nov 17, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Matan-B Nov 18, 2025

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Matan-B commented Nov 19, 2025

Uh oh!

Matan-B commented Nov 19, 2025

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Matan-B commented Nov 13, 2025 •

edited

Loading

Matan-B Nov 17, 2025 •

edited

Loading