Comment 10 for bug 1894453

@Corey Bryant, I think Ceph simply specifies rocksdb version to be used in the submodule information.

1. I checked out the tag v15.2.3 (upstream): git checkout tags/v15.2.3 -b 15.2.3
  (which src/rocksdb is an empty directory)

2. Initialize submodule indexes: git submodule update --init

3. The commit HEAD of rocksdb that Ceph 15.2.3 uses:
 $ git submodule status | grep rocksdb
 4c736f177851cbf9fb7a6790282306ffac5065f8 rocksdb (v5.8-1436-g4c736f177)

I think this is how Ceph upstream "matches" the versions of various submodules (rocksdb is one of them) for a given Ceph release.

Comparing the above cloned rocksdb matches exactly with UCA's repo. So I think the UCA's repo is upto date and there's no such problem of using "older" version of rocksdb as I speculated.

So the question is whether we want to cherry-pick build change from upstream so as compile rocksdb with RelWithDebInfo or wait until upstream defaults to a newer rocksdb submodule that does build with RelWithDebInfo by default.

P.S: One thing I don't know is what mechanism upstream follow before they decide to use
a newer version of rocksdb. For example, the rocksdb version 6.8.1 contains the change
to use 'RelWithDebInfo' - which was released/tagged on April 17th [0] as part of Ceph repo. But the Ceph 15.2.3 release [1] that was done on May 29 didn't include that but uses an older version of rocksdb (as noted initially in the comment). My guess is that upstream always integrate recent rocksdb commits in Ceph master for testing/development purposes. But when it comes to release, they choose the one that they think is stable.

[0] https://github.com/ceph/rocksdb/releases

[1] https://github.com/ceph/ceph/releases