> I kinda feel this should be separated as we can and do do this today but the reason we have not grouped is not due to the framework we use but more “what makes sense to group”
I think that's more or less correct. The critical path thing here is getting to consensus (in CASSANDRA-17292 <https://issues.apache.org/jira/browse/CASSANDRA-17292>) on what we actually want a future nested YAML that a user will interact with to look like. How we implement it and how we ensure backwards compatibility/version the YAML are separate questions (questions that will probably be answered in part by things like the efficiency of the framework around read costs, etc.) On Thu, Mar 14, 2024 at 11:44 AM David Capwell <dcapw...@apple.com> wrote: > Just went over the doc and I don’t see a real argument for why we want to > switch “frameworks”… I think this should be fleshed out more; what is it we > are actually solving for? > > Also, I “think” its trying to propose we switch from a mostly flat yaml to > a nested structure… I kinda feel this should be separated as we can and do > do this today but the reason we have not grouped is not due to the > framework we use but more “what makes sense to group” (lack of agreement > and consistency here… ). There was a JIRA that Caleb worked on and him and > Benedict came up with a proposal, I recommend taking a look at that past > work if you wish to do something similar. > > We all have to maintain our configs, so we need to be able to answer a few > questions with this type of proposal > > 1) how will developers maintain, and does this add any burdens to them? > What benefits do I get as a maintainer? > 2) what are the read costs. During a single CQL command we do many > accesses to Config to see what we should and should not do/allow, so the > costs here must be known or easy to understand. > 3) config is a critical and core part of the code, so a rewrite comes with > huge risk and cost, do we have equal or greater reward for this? What are > those rewards? What are those risks? > 4) can the motivations for this work be solved in a different way that > improves one or more of the above questions? Why is your proposal more > desirable than those solutions? > > > On Mar 13, 2024, at 12:15 PM, Maxim Muzafarov <mmu...@apache.org> wrote: > > > > Hello everyone, > > > > During the implementation, many valid design comments were made about > > making the virtual table SettingTable [1] updatable. So, I've > > rethought the whole concept once again, and I want to take another > > step forward to make this problem feasible with less effort on our > > part. > > > > I want to replace the way we use and store node configuration values > > internally, which means I want to replace the Config class instance, > > where we store values with a tree-based framework. > >>> I propose to use the Lightbend API to do this. << > > > > The changes themselves are quite limited, they don't require rewriting > > the whole codebase. All the DatabaseDescriptor methods will be > > retained, and the only thing that would change is the way we store the > > values (in the in-memory tree, not in the Config class instance > > itself). So I don't expect that it will be a huge change. > > > > > > All the design details are in the document below, including the > > framework comparison, the API, and the way how we will manage the > > configuration schema. > > > > Please take a look, I want to move things forward as every important > > change pulls on a bigger problem that has been neglected for years :-) > > Let's agree on the framework/API we want to use so that I can invest > > more time in the implementation. > > > > > https://docs.google.com/document/d/11W1Qj-6d9ZqHv86iEKgFutcxY2DTMIofEbr-zQiw930/edit#heading=h.2051pbez4rce > > > > Looking forward to your comments. > > > > [1] https://issues.apache.org/jira/browse/CASSANDRA-15254 > >
