could we hide the distinction from users? we're trying to avoid exposing the alienstore name anyway.

if we kept the osd_objectstore setting the same, and handled the different types of bluestore/memstore internallly, we wouldn't need to modify higher level tools like ceph-volume as well.

@jdurgin, This issue was actually caught when the cephadm support was added few weeks ago - the crimson_osd_objectstore is no longer used and was removed. We now use osd_objectstore same as classic.
#63817

@jdurgin, @Matan-B: it's hard. I see the point behind "candifying" the thing for users which, purely from the developer's point-of-view, I need to dislike because of complexity and unintended side-effects.

Technically speaking, these configurables are disjoint – crimson has its own set of values, completely different from classical's. Sure, by allowing a daemon to signal senseless choices (e.g. seastore for classical) on its own we can bail out. The price is complexity and ugliness – OSD would need to bypass the configuration subsystem's checks and implement its own.

I agree that alienstore-bluestore is too-technical to be exposed to users (maybe crimson-bluestore would be better?) but just blurring the distinction between bluestore and the crimson's variant brought the problem of unintended upgradeability.

Finally, we'll need to ensure that the OSD variants are able to co-exists for the sake of e.g. data migration. This also means testing with heterogeneous vstart.sh clusters where the need to control the configurables separately can be seen even now.
My intuition is that something is missed. Should we introduce a new entity class for crimson (to have dedicated category spanning all crimson instances in the config subsystem)? I bet that managing the mix on the osd-by-osd basis will be burdensome.

@rzarzynski, I think we misunderstood each other here. Josh comment was regarding hiding the distinction from users prespective of the option name . Meaning to use osd_objectstore and not a dedicated crimson_osd_objectstore.
This change is already merged and is not related to the PR here - and shouldn't block by any means.
I agree with the suggestion above to use crimson-bluestore instead of alienstore-bluestore, as we try to keep alien an internal dev concept.

I wrote precisely about hiding this distinction. From engineer's POV osd_objectstore is genuinely different from the now-removed crimson_osd_objectstore.

Should we add an else if here when bluestore is used that crimson-bluestore should be used instead?
I'm afraid: unsupported objectstore type: bluestore might be confusing.

Yeah, people may (and will) think "bluestore" while we really want to make a distinction at the naming.

This extra clause should be there. I will add a commit.

This option name (crimson_osd_objectstore) is removed, I think these options should be added to the global osd_objectstore instead.

What do you think about keeping the singular osd_objectstore but using a crimson- prefix for the dedicated crimson objcet stores?

  enum_values:
  - bluestore
  - memstore
  - crimson-bluestore
  - crimson-memstore
  - crimson-seastore
  - crimson-cyanstore

This looks nice from UI designer's POV.
After putting the engineer's hat I need to point some ugliness in bypassing the generic, config subsystem-level check for this enum.
There are also some worries about heterogeneous clusters and vstart.sh.

The rebased branch preserves the approach with crimson prefixing at the name of the config option.
I don't see a possibility to unify with the classical – even in the alternative approach (crimson-bluestore, crimson-seastore...) the prefixing is present (just becomes prefixing of values) but at at overall higher cost IMHO: bringing non-sensual choices to classical and compromising the enum(we would have some unsupported values but differentiated depending on OSD). Having thealienstore` word is IMHO useful as it clearly divides what's native and what's ported.

I'm ok with separating the two into a unique crimson backend option. However, merging this PR as-is would break higher level tools (cephadm/vol). What do you think about moving this change out of this PR and follow-up with a PR that would change the options and adjust the relevant tools usage?

Otherwise, main branch wouldn't be able to deploy crimson via cepadm due to the new option.

Hmm, this might work as the object store's factory method seems to be decoupled from the type that BlueStore writes in its metadata.