> > 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.
Makes sense, I think this would be good to have as a lint or test to easily catch overlooks during review. On Fri, Jan 24, 2025 at 9:44 AM Štefan Miklošovič <smikloso...@apache.org> 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. >>> >>
