2. We want to preserve a hierarchical description of the cluster that is easy to view and understand by the user. For example, all OSDs on host cpach are under that node in the tree.

3. We want to make rules that can apply to a specific type of device. For example, a cephfs metadata pool that uses SSDs only.

CRUSH has a "type" that is used to describe non-device nodes (host, rack, row,root), but all devices are the same (type==0). And the hierarchy is summedand weighted based on all devices. In order for an ssd-only rule to doa placement and traverse the tree, it would need a set of weights that onlyinclude ssd devices.

Include derivative bucket ids for each class in the decompiled bucket. These, like ID, areselected automatically if not specified during compile, but are included on decompile so that a decompile -> compile cycle generates the same tree with the same bucket ids.

Is there a reason to expose the generated bucket id to the user ? Also, the weight associated with the ssd bucket is unlikely to be the same as the weight of the hdd bucket. Either we need to show them separated entirely:

<loicd> sage: I'm confused by how we should handle the weights with the device classes. The weight of the generated buckets will have to be updated based on the weight of the leaf devices they contain. There is no way to guess what the user intented if the weights in the input crushmap have been manually updated. It also means that if we expose the generated buckets and allow the user to modify their weight via ceph osd ..., we cannot decompile the crushmap extracted from the mon without exposing each bucket explicitly.<sage> i suggest we don't allow the user to decompile the generated buckets<sage> and for the weights, stick with a strict hierarchical weighting.<sage> if the user specifies weights in the main tree that don't sum up, issue a warning during compile<sage> (they really should be doing that anyway)<sage> *shouldn't<loicd> ok, that makes sense to me, thanks for the input