+1 to making hidden properties explicit. No way to tell whether it's a mistake or not atm.
On Fri, Jan 24, 2025, at 9:36 AM, Štefan Miklošovič wrote: > > > On Fri, Jan 24, 2025 at 3:27 PM 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. > > Yes, then can stay hidden, but we should annotate it with @Hidden or similar. > As of now, if that property is not in yaml, we just don't know if it was > forgotten to be added or if we have not added it on purpose. > > They can keep being commented out if they currently are. Imagine a property > in Config.java > > public boolean my_cool_property = true; > > and then this in cassandra.yaml > > # my_cool_property: true > > It is completely ok. > > If "# my_cool_property: true" is NOT in cassandra.yaml, we might indeed add > it, also commented out. I think it would be quite easy to check against yaml > if there is a line starting on "# my_cool_property" or just on > "my_cool_property". Both cases would satisfy the check. > > >> > 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. > > Yeah, good idea. > >> >> 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.
