I would say just go with it. JMX isn’t quite deprecated yet, and if we ever even end up doing that, it’s not going to be any time soon.
> On 16 Jul 2021, at 13:32, Stefan Miklosovic > <stefan.mikloso...@instaclustr.com> wrote: > > 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
