That seems like a bug, the order should not matter. I see how / why it fails in the code. I will try to come up with a solution and fix.
Thank you for reporting it. Regards On Tue, Sep 10, 2024 at 9:46 AM Michael Burman <y...@iki.fi> wrote: > Hi, > > While we were testing the 5.0.0, I stumbled upon a feature (bug) that has > made the cassandra.yaml an order dependent configuration file. As an > example, the following works: > > memtable: > configurations: > skiplist: > class_name: SkipListMemtable > trie: > class_name: TrieMemtable > default: > inherits: trie > > But configuring the same options with a different order: > > memtable: > configurations: > default: > inherits: trie > skiplist: > class_name: SkipListMemtable > trie: > class_name: TrieMemtable > > Will cause 5.0.0 to fail start: > > Caused by: org.apache.cassandra.exceptions.ConfigurationException: > Configuration definition inherits unknown trie. A configuration can only > extend one defined earlier or "default". > > Is this change intentional or just an oversight? This breaks the YAML > specification as seen here https://yaml.org/spec/1.2.2/#mapping since the > map elements now have restricted ordering. In practical terms it breaks a > lot of tools that are used to generate the cassandra.yaml since most of the > YAML processors do not care about ordering and this is very apparent with > any tool written in Go where the map does not intentionally preserve order > (and this includes for example the default yaml marshaller/unmarshaller > where just reading the file and outputting it will prevent 5.0.0 from > starting). > > - Micke >