I don't see the two formats being mutually exclusive. For example, if
only one option is different from the default in a deeply nested
structure, it would be far easier to set "a.b.c.d.e: true" than having 5
lines in the config file. Mixing both formats in the same settings file
seems like a
Great discussion.
It would be an implementation detail but we could imagine having a single
interface for reading config and providing readers for old or/and new
configuration formats. If we can streamline reading of all configs from
that single interface we would have much centralized (following
If we support both formats for a time, I just would want to make absolutely
sure that it will read only one or the other so there's no uncertainty about
the server configuration. Perhaps to avoid unforeseen migration problems, we
only read the old format if a specific flag is set? So with
Continuing to parse the old format for some time seems unavoidable, and
allowing dot-separated options in the old format seems reasonable.
There will certainly be some interesting problems when we move into
implementation space with this. One approach might be to implement a clean
object model
I agree with Benedict, there's legit use cases for both the flat and
structured config file format. The operator should be able to choose
which one is best suited for their own use case. It will also make the
upgrade process easier if both formats are supported by future versions
of Cassandra.
As this is a major change including structural aspects as well as the
separation of feature configuration, it came to my mind, why do we stuck with
YAML as envelope? Many aspects already in discussion may be covered with
already existing tools. Would it worth considering, e.g. Typesafe Config
