> a) Allow VirtualTables to be settable - to support changing parameters (ie.
> nodetool setcompactionthroughput 32).
Can be accomplished by updating or inserting on the settings virtual table
via
UPDATE system_views.settings SET value = 32 WHERE name =
'compaction_throughput';
INSERT INTO system_views.settings (name, value) VALUES
('compaction_throughput', 32);
It also aligns configuration in yaml names with what you use to update it
at runtime, vs having different naming and one off commands for each
individual setting. That was pushed off in the settings virtual table for
post 4.0 however. (see original patch in
https://issues.apache.org/jira/browse/CASSANDRA-14573)
There is a long way to deprecate JMX though, a lot of things are absolutely
necessary before even considering it like
https://issues.apache.org/jira/browse/CASSANDRA-14629
Chris
On Fri, Jul 16, 2021 at 11:39 AM Aleksey Yeschenko <alek...@apache.org>
wrote:
> 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
>
>
