CI failures look bogus.

@MaxKellermann
I am curious - can you share why WITH_BLUESTORE is not set?
I was thinking along the direction of removing it and making bluestore compile always.

I tried to build Ceph with the lightest dependencies possible; I don't even know what Bluestore is, but I guess it's not relevant at all for me because my work is only about the MDS.

But generally I wouldn't want you to make any more dependencies mandatory. Building Ceph is very difficult already, and adding more mandatory dependencies would make it more difficult. Why would I want to have all those dependencies when all I want to work on is the MDS? I like software that is (compile-time) configurable and making that possible is easy enough (even though Ceph is sometimes more clumsy than necessary about it - it could have been easier in the code). I think allowing a bare-minimal build is a good idea, and my idea was actually to make more dependencies optional.

There could be more CI tests verifying all the build combinations, but unfortunately Ceph's CI test fail for bogus reasons more often than not, and then the CI takes several hours to finish. Partly because the header dependency bloat is horrible (see #60490), partly because Boost::async is used (which adds dependency bloat that cannot be undone without removing asio completely, which I would support and even help implement), and partly because Ceph's CI doesn't take advantage of ccache.

@MaxKellermann
I get your point. I share your opinon on expanding external dependencies.
BlueStore is a mandatory component of ceph. It is used in OSD to store the data.
Currently, no classic deployment can work without it.

But I get your point on compilation of independent modules.

@MaxKellermann
I think the best dependency chain with regard to WITH_BLUESTORE should be like:
If not compiling OSD, skip "test/objectstore" and all its content.

WITH_BLUESTORE should not be referenced anywhere else.

@aclamk, how to proceed? This PR fixes a build failure, but does not refactor existing code. Your last comment 3 weeks ago might be an idea to refactor the code, but that's not my goal - I think merging a minimal build failure fix now is the right way to go, and whoever is interested in refactoring may do this at any time.

Hello, anybody?

Hello, @aclamk? Anybody else?

Can one of the admins verify this patch?

@MaxKellermann I will take this path in next teuthology run; I expect no problems. Will update you.

jenkins test api

jenkins test make check arm64

jenkins test docs

jenkins test make check arm64

https://tracker.ceph.com/issues/69756 passed