> 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!) > > >
