That's a good point. It seems to be able to fully deprecate JMX we will need the following: a) Allow VirtualTables to be settable - to support changing parameters (ie. nodetool setcompactionthroughput 32). b) Support CALL/EXECUTE/INVOKE CQL statements for things like flush and compact etc.
When laying out the proposal, I was thinking only about a phased deprecation, starting with purely informational JMX statements (ie. getters) which can already be served by the current VirtualTables support. As soon as we have support for b) and c) we could extend the deprecation to setters and invokers. I personally think it makes sense to take an incremental approach to JMX deprecation starting with getters, since the majority of JMX calls are informational and non-state-changing, representing a big chunk of the work. Perhaps people feel differently and think it only makes sense to deprecate JMX when we have full operation parity with CQL. Em sex., 16 de jul. de 2021 às 08:39, Benjamin Lerer <ble...@apache.org> escreveu: > > > > 1) Are people OK with drawing a line after current in-progress patches > are > > finished and formally disallowing new features from being added to the > JMX > > interface, but only to VT? If not, what are the concerns and how can we > > address them. > > > Virtual Tables are not really suitable for all nodetool commands. For > example for commands like flush or compact that do not return values but > are simply some triggers. What would be the plan for those? Add some > specific CQL calls? > > > > Le ven. 16 juil. 2021 à 13:16, Paulo Motta <pauloricard...@gmail.com> a > écrit : > > > > It seems only fair to me to let these patches go in and simply thank > the > > contributors for their efforts and work. We can open some followup > tickets > > for providing those functionalities > > through Virtual Tables (we are only talking about 2 patches). If nobody > > else takes them, I will. > > > > +1 Sounds like a reasonable compromise to me, we can just treat the > > in-progress patches as legacy features and migrate them later to VT. I > just > > don't want to see the focus of this important discussion diverted to this > > detail. > > > > I think the important points to discuss are: > > 1) Are people OK with drawing a line after current in-progress patches > are > > finished and formally disallowing new features from being added to the > JMX > > interface, but only to VT? If not, what are the concerns and how can we > > address them. > > 2) Are people OK with providing a hybrid support mode to nodetool, where > > VirtualTable data is exposed via JMX in order to allow JMX functionality > to > > be progressively migrated to VirtualTables without user impact? If not, > > what are the concerns and how can we address them. > > 3) What to do about driver support for fetching VT information about a > > specific node? > > > > What we're not discussing: > > - Deprecating nodetool, since this depends on the JMX functionality to be > > fully migrated to VirtualTables, a later step in the distant future. > > > > Once we have a general agreement about these 3 points (and any other > points > > someone thinks it's relevant to the discussion) I can take some time to > > format a CEP detailing the proposal - and we can obviously re-discuss the > > details into a formal [DISCUSS] thread once the CEP is created. But this > > doesn't preclude us from having a pre-CEP discussion to gather some > initial > > feedback about the proposal. > > > > Em sex., 16 de jul. de 2021 às 05:44, Benjamin Lerer <b.le...@gmail.com> > > escreveu: > > > > > Thanks a lot for all the feedback, I really appreciate the discussion > and > > > Paulo's proposals. > > > > > > Regarding the ongoing patches: > > > > > > Based on the discussion, it clearly appears that nodetool will still be > > > there for some time (and will be there in the next major release). > > > As such, it seems to me that the current ongoing patches to add new > > > nodetool commands will be useful. > > > I honestly do not see the point at this stage of preventing them from > > going > > > in and I can totally understand the frustration of the people that have > > > spent time on making them. > > > I did not trigger that discussion with that goal in mind. My goal was > > more > > > to clarify our strategy for the future. > > > > > > It seems only fair to me to let these patches go in and simply thank > the > > > contributors for their efforts and work. > > > We can open some followup tickets for providing those functionalities > > > through Virtual Tables (we are only talking about 2 patches). > > > If nobody else takes them, I will. > > > > > > > > > Le ven. 16 juil. 2021 à 10:17, Mick Semb Wever <m...@apache.org> a > écrit > > : > > > > > > > > > > > > > > Until CEP exists and is approved, work on patches in flight seems > > > > > reasonable and valid. > > > > > > > > > > This is right, but when there is an active discussion about > changing > > > the > > > > > status quo it's polite to wait for the outcome of the discussion - > or > > > > help > > > > > it make progress - before making potentially conflicting changes. > > > > > > > > > > > > > > > > > Totally agree. > > > > This question has been asked many times, and is often getting > answered > > by > > > > fragmented groups. The broader discussion is definitely warranted > > (thank > > > > you Benjamin). > > > > > > > > Stefan, looking at the patch for CASSANDRA-16725, it is only intended > > for > > > > trunk so it has 6 months to land. I'm definitely in favour of seeing > it > > > > also be put into a vtable. It doesn't change the patch much, just an > > ask > > > > for a trivial class to be added, and that is a reasonable request to > > make > > > > through the review rounds. (A few rounds during the review like this > is > > > > _perfectly normal_, and is only going to improve the patch in other > > > areas, > > > > like changing the code to use Config.PROPERTY_PREFIX and > > > > CassandraRelevantProperties). > > > > But I can take this feedback to the ticket. Also happy to help out > (as > > > any > > > > reviewer that makes a suggestion should be!) > > > > > > > > > >
