Hi, I've just thought about the same as Stefan - can we automate this consistency check.. (the topic is actually triggered by our recent review). I definitely saw some other existing options which are available in Config but not mentioned in cassandra.yaml. The case with intentionally hidden options can be covered using some annotation like @Hidden for such properties in Config.java It will allow you to declare the intent to not expose this option clearly. The main complexity from technical point of view I see is that we declare some of the properties only in comments in cassandra.yaml and it can be non-trivial to parse them.
update: Stefan has suggested the annotation as well while I was writing the mail :-) On Fri, 24 Jan 2025 at 14:26, Paulo Motta <pa...@apache.org> wrote: > > from time to time I see configuration properties in Config.java and they > are clearly not in cassandra.yaml. Not every property in Config is in > cassandra.yaml. I would like to know if there is some specific reason > behind that. > > I think one of the original reasons was to "hide" advanced configs that > are not meant to be updated, unless in very niche circumstances. However I > think this has been extrapolated to non-advanced settings. > > > Question related to that is if we could not have a build-time check that > all properties in Config have to be in cassandra.yaml and fail the build if > a property in Config does not have its counterpart in yaml. > > Are you saying every configuration property should be commented-out, or do > you think that every Config property should be specified in cassandra.yaml > with their default uncomented ? One issue with that is that you could cause > user confusion if you "reveal" a niche/advanced config that is not meant to > be updated. I think this would be addressed by the @HiddenInYaml flag you > are proposing in a later post. > > > There are dozens of properties in Config and I have a strong suspicion > that we missed to publish some to yaml so users do not even know such a > property exists and as of now we do not even know which they are. > > I believe this is a problem. I think most properties should be in > cassandra.yaml, unless they are very advanced or not meant to be updated. > > Another tangential issue is that there are features/settings that don't > even have a Config entry, but are just controlled by JVM properties. > > I think that we should attempt to unify Config and jvm properties under a > predictable structure. For example, if there is a YAML config > enable_user_defined_functions, then there should be a respective JVM flag > -Dcassandra.enable_user_defined_functions, and vice versa. > > On Fri, Jan 24, 2025 at 9:16 AM Štefan Miklošovič <smikloso...@apache.org> > wrote: > >> Hello, >> >> from time to time I see configuration properties in Config.java and they >> are clearly not in cassandra.yaml. Not every property in Config is in >> cassandra.yaml. I would like to know if there is some specific reason >> behind that. >> >> Question related to that is if we could not have a build-time check that >> all properties in Config have to be in cassandra.yaml and fail the build if >> a property in Config does not have its counterpart in yaml. >> >> There are dozens of properties in Config and I have a strong suspicion >> that we missed to publish some to yaml so users do not even know such a >> property exists and as of now we do not even know which they are. >> > -- Dmitry Konstantinov
