Thanks Benjamin for the understanding, but in the end, let's put aside the frustration here, I think I can just kind of detach from that.
However, in this particular case, I really think we should just finish this and merge it and move on. By not doing so and waiting for the CEP around this, we are just opening ourselves to a possibility that it will not be finished / implemented and we will live without that command. In other words, I just do not like to not do something, when it just lies in front of me, just because of some assumption we make that something will happen in the future. I do not get this approach. The future might just change. Plus this is just an easy patch, no big deal, it is not like I would have to revert the heaps of code to accommodate future features. If I do not merge it, I am afraid this might happen: A user (lets call him Tommy), is excited about 4.0, they are using some custom auditing and he wants to give a shot to native stuff we provide here. So he goes and downloads, tries it, all is good. Then he realises that it was a long time ago he set this up, messed with that a bit and kept it running. But after a while, he forgot how he set it up. So he looks into nodetool and sees, yay, enableauditlog, disableauditlog, there are a bunch of get* commands too, but no status of audit log? How can I know how that is set up? So Tommy reaches the community and says that hey, you are missing that command, am I going to see it in 4.1 or in some patch release at least to get it sooner? And we reply: Dear Tommy, we know it is missing, but wait! There is this CEP we are working day and night on, it will solve the world hunger and it will be the best thing since the sliced bread, you just have to wait a little bit longer, because there are other things going on right now and it seems to take longer than expected, lot of problems on the way, so maybe return in 4.3 and there you get it. But Tommy does not care. He truly does not. He just wants to query the state of the audit log by any means necessary. And once this happens multiple times he just goes away. By the way, I really think this is a little bit more complicated than it seems. It is hard to guess how the implementation will look like but in our original discussion with Paulo, we were thinking about having a completely separate repository for this where only the client would be. There are few benefits - it might be just released independently, if we truly separate this and we talk only CQL, I do not see any reason why we should depend on the main Cassandra repository. It also lowers the barrier for other people who would want to implement the command they miss. However, I get that while we want to support both approaches, it will be done and probably it has to be done together, but I am afraid that we will just introduce a hybrid which would take ages to finish fully so we can announce JMX deprecated. There are a lot of commands to be migrated as well and having a separate repository would at least make the main repo less noisy. But since I am not fully aware of what approach we end up with and how the implementation would look like in the end, I can not fully advocate the separate repository approach because it might be just rendered ineffective and wrong. That's just my rambling here but I would just close the issue with 16725 by merging that and then we can fully focus on CEP and all things related. Sounds good to everybody? Regards On Fri, 16 Jul 2021 at 10:44, Benjamin Lerer <b.le...@gmail.com> wrote: > > 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!) > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
