You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cassandra.apache.org by Benjamin Lerer <bl...@apache.org> on 2021/07/15 12:34:34 UTC
[DISCUSS] Virtual Tables and the future of NodeTool/JMX
Hi everyone,
When Virtual Tables/System Views were introduced in 4.0 it was with the
intention to provide a more friendly way than JMX and NodeTool to manage
and monitor nodes.
In CASSANDRA-16404 <https://issues.apache.org/jira/browse/CASSANDRA-16404>,
Sam raises the point that it might make sense from now on to stop adding
functionalities to NodeTool and to provide them through Virtual Tables.
My initial feeling was that we could provide both until we decided to
deprecate NodeTool but that would require some extra work and as such might
not be a good strategy.
What is your opinion on this?
Re: [DISCUSS] Virtual Tables and the future of NodeTool/JMX
Posted by "J. D. Jordan" <je...@gmail.com>.
As long as the implemented nodetool commands are still going over JMX I see no issue.
The problem lies when you need native transport access. In a secured cluster you possibly need an entirely new set of access information (username, password, ssl certificate) depending on how JMX access and native transport access are setup. You also possibly need access to different ports allowed if the admin client is remote. I think it is burdensome on the end user if we require them to have both JMX and native transport setup and configured for operational access and then also to know which set of access information to use on a per command basis.
-Jeremiah
> On Jul 15, 2021, at 2:59 PM, Brandon Williams <dr...@gmail.com> wrote:
>
> On Thu, Jul 15, 2021 at 8:59 AM Paulo Motta <pa...@gmail.com> wrote:
>>
>> Perhaps one approach to expose VirtualTables via nodetool without requiring
>> the user to provide CQL credentials would be to provide a generic
>> StorageServiceMBean.queryVirtualTable(String name) JMX method returning a
>> TabularData result. This would allow to keep a consistent nodetool frontend
>> to users while progressively switching the backend from JMX to
>> VirtualTables.
>
> I like this idea. +1
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> For additional commands, e-mail: dev-help@cassandra.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
For additional commands, e-mail: dev-help@cassandra.apache.org
Re: [DISCUSS] Virtual Tables and the future of NodeTool/JMX
Posted by Jeff Jirsa <jj...@gmail.com>.
On Thu, Jul 15, 2021 at 12:59 PM Brandon Williams <dr...@gmail.com> wrote:
> On Thu, Jul 15, 2021 at 8:59 AM Paulo Motta <pa...@gmail.com>
> wrote:
> >
> > Perhaps one approach to expose VirtualTables via nodetool without
> requiring
> > the user to provide CQL credentials would be to provide a generic
> > StorageServiceMBean.queryVirtualTable(String name) JMX method returning a
> > TabularData result. This would allow to keep a consistent nodetool
> frontend
> > to users while progressively switching the backend from JMX to
> > VirtualTables.
>
> I like this idea. +1
>
You lost me at "without requiring the user to provide CQL credentials"
Re: [DISCUSS] Virtual Tables and the future of NodeTool/JMX
Posted by Brandon Williams <dr...@gmail.com>.
On Thu, Jul 15, 2021 at 8:59 AM Paulo Motta <pa...@gmail.com> wrote:
>
> Perhaps one approach to expose VirtualTables via nodetool without requiring
> the user to provide CQL credentials would be to provide a generic
> StorageServiceMBean.queryVirtualTable(String name) JMX method returning a
> TabularData result. This would allow to keep a consistent nodetool frontend
> to users while progressively switching the backend from JMX to
> VirtualTables.
I like this idea. +1
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
For additional commands, e-mail: dev-help@cassandra.apache.org
Re: [DISCUSS] Virtual Tables and the future of NodeTool/JMX
Posted by Aleksey Yeschenko <al...@apache.org>.
We could eventually make a virtual table only mode to resolve this - not serve any data until a node is ready to do so - if necessary.
> On 15 Jul 2021, at 17:43, Jeff Jirsa <jj...@gmail.com> wrote:
>
> There's a tactical issue, too, that virtual tables require native transport
> to be up before it's usable, so for things pre-startup (e.g. querying
> streaming state during bootstrap), so I don't think nodetool/jmx dies
> entirely ever (or, a non-client-facing-virtual-tables-only port has to be
> created, but that's much more involved obviously)
>
> On Thu, Jul 15, 2021 at 9:18 AM Lorina Poland <lo...@datastax.com> wrote:
>
>> I think it is important to keep in mind that users may be utilizing
>> nodetool programmatically, in scripts. Obviously, those scripts could use
>> calls to cqlsh as an alternative, but I'm a fan of keeping nodetool intact,
>> building out virtual table capability, and then deprecating nodetool. In
>> other words, only deprecate/remove nodetool commands once a *whole*
>> replacement is available. And then deprecate slowly, perhaps with migration
>> help in the docs for nodetool -> virtual tables.
>>
>> Lorina
>>
>> On Thu, Jul 15, 2021 at 6:59 AM Paulo Motta <pa...@gmail.com>
>> wrote:
>>
>>> Perhaps one approach to expose VirtualTables via nodetool without
>> requiring
>>> the user to provide CQL credentials would be to provide a generic
>>> StorageServiceMBean.queryVirtualTable(String name) JMX method returning a
>>> TabularData result. This would allow to keep a consistent nodetool
>> frontend
>>> to users while progressively switching the backend from JMX to
>>> VirtualTables.
>>>
>>> We could create a framework to automatically expose a basic nodetool
>>> getter/setter command whenever a new virtual table is added, making the
>> new
>>> feature visible to non-power nodetool users while requiring little
>>> additional effort from the VirtualTable implementor.
>>>
>>> When migrating commands from JMX to VirtualTables we could just update
>> the
>>> legacy nodetool command implementation to access the virtual table via
>> the
>>> generic StorageServiceMBean.queryVirtualTable(String name) method while
>>> keeping the output consistent with the previous implementation, and
>>> deprecating their JMX counterpart.
>>>
>>> Ultimately when all commands are migrated from JMX to VirtualTables we
>>> could decide if we want to keep the nodetool CLI, acessing all virtual
>>> tables via the generic JMX virtual table accessor, or to deprecate
>> nodetool
>>> altogether and tell users to query virtual tables directly via cqlsh
>>> instead.
>>>
>>> Em qui., 15 de jul. de 2021 às 10:34, Paulo Motta <
>>> pauloricardomg@gmail.com>
>>> escreveu:
>>>
>>>> Thanks for bringing this discussion Benjamin. I raised a similar point
>> in
>>>> CASSANDRA-16725 <https://issues.apache.org/jira/browse/CASSANDRA-16725
>>>
>>>> and it may become a recurrent topic now the code freeze is lifted and
>>> more
>>>> contributors will want to add new administrative commands to nodetool
>> so
>>>> it's important that we discuss and decide a consistent approach to this
>>>> transition moving forward.
>>>>
>>>> I was planning to write a CEP to propose a migration strategy from JMX
>> to
>>>> Virtual tables but since this discussion came before I will detail my
>>>> thoughts so far.
>>>>
>>>> I think that we should add new commands exclusively to Virtual Tables
>> and
>>>> progressively migrate existing nodetool/JMX commands to
>> VirtualTables/CQL
>>>> until we ultimately get rid of JMX/nodetool. Nevertheless, from the
>> user
>>>> point of view it may be inconvenient/confusing to have administrative
>>>> commands split between different interfaces so we need to think about
>>> this
>>>> transition carefully to provide the best possible user experience.
>>>>
>>>> My motivation for CASSANDRA-16513 <
>>>> https://issues.apache.org/jira/browse/CASSANDRA-16513> was that we're
>>>> already providing some functionalities exclusively via Virtual Tables,
>> so
>>>> these features may not be visible to non-power users which are
>> accustomed
>>>> to the nodetool CLI interface for admin commands. The original plan for
>>>> that ticket was to make nodetool abstract away the underlying interface
>>>> (JMX, CQL) for administrative commands, so we would expose admin
>>>> functionality via the same CLI interface (nodetool) to users while
>>>> progressively migrating the backend from JMX to CQL/VirtualTables.
>>>>
>>>> Some people raised the concern that this could cause confusion among
>>> users
>>>> about which credentials to use if JMX or CQL for nodetool. Based on
>> this
>>>> feedback I adapted the proposal to create an entirely different
>>>> administrative CLI tool (which I called admintool) to access/modify
>>> virtual
>>>> tables. In this proposal new administrative commands would be added
>>>> exclusively to Virtual Tables and would automatically land on this
>> tool,
>>>> and legacy nodetool commands (via JMX) would be progressively migrated
>> to
>>>> admintool (CQL/VT) until the migration is completed. The drawback of
>> this
>>>> alternative proposal is that it would still split administrative
>> commands
>>>> between different CLI tools.
>>>>
>>>> So, if we decide to stop adding new admin functionality to JMX we have
>> a
>>>> few options to make this transition smoother for our users:
>>>> 1) Do nothing and tell users some admin functionalities will be
>>> accessible
>>>> exclusively via cqlsh/virtual tables - imo this option is the least
>>>> user-friendly.
>>>> 2) Make nodetool hybrid and provide a consistent interface to users
>> while
>>>> abstracting away the backend (JMX/CQL)
>>>> 3) Create a new CLI tool (admintool) to provide CLI access to virtual
>>>> tables and tell users to use both nodetool and admintool.
>>>>
>>>> I personally think option 2 is the least disruptive to users during the
>>>> transition phase since people are already used to using nodetool so we
>>> can
>>>> provide a seamless transition to JMX while keeping the CLI tool for
>>> legacy
>>>> users. Even though there are concerns of confusion of which credentials
>>> to
>>>> use on nodetool if we support both interfaces, we can make sure this is
>>>> well documented.
>>>>
>>>> Em qui., 15 de jul. de 2021 às 09:35, Benjamin Lerer <
>> blerer@apache.org>
>>>> escreveu:
>>>>
>>>>> Hi everyone,
>>>>>
>>>>> When Virtual Tables/System Views were introduced in 4.0 it was with
>> the
>>>>> intention to provide a more friendly way than JMX and NodeTool to
>> manage
>>>>> and monitor nodes.
>>>>>
>>>>> In CASSANDRA-16404 <
>>> https://issues.apache.org/jira/browse/CASSANDRA-16404
>>>>>> ,
>>>>> Sam raises the point that it might make sense from now on to stop
>> adding
>>>>> functionalities to NodeTool and to provide them through Virtual
>> Tables.
>>>>> My initial feeling was that we could provide both until we decided to
>>>>> deprecate NodeTool but that would require some extra work and as such
>>>>> might
>>>>> not be a good strategy.
>>>>>
>>>>> What is your opinion on this?
>>>>>
>>>>
>>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
For additional commands, e-mail: dev-help@cassandra.apache.org
Re: [DISCUSS] Virtual Tables and the future of NodeTool/JMX
Posted by Jeff Jirsa <jj...@gmail.com>.
There's a tactical issue, too, that virtual tables require native transport
to be up before it's usable, so for things pre-startup (e.g. querying
streaming state during bootstrap), so I don't think nodetool/jmx dies
entirely ever (or, a non-client-facing-virtual-tables-only port has to be
created, but that's much more involved obviously)
On Thu, Jul 15, 2021 at 9:18 AM Lorina Poland <lo...@datastax.com> wrote:
> I think it is important to keep in mind that users may be utilizing
> nodetool programmatically, in scripts. Obviously, those scripts could use
> calls to cqlsh as an alternative, but I'm a fan of keeping nodetool intact,
> building out virtual table capability, and then deprecating nodetool. In
> other words, only deprecate/remove nodetool commands once a *whole*
> replacement is available. And then deprecate slowly, perhaps with migration
> help in the docs for nodetool -> virtual tables.
>
> Lorina
>
> On Thu, Jul 15, 2021 at 6:59 AM Paulo Motta <pa...@gmail.com>
> wrote:
>
> > Perhaps one approach to expose VirtualTables via nodetool without
> requiring
> > the user to provide CQL credentials would be to provide a generic
> > StorageServiceMBean.queryVirtualTable(String name) JMX method returning a
> > TabularData result. This would allow to keep a consistent nodetool
> frontend
> > to users while progressively switching the backend from JMX to
> > VirtualTables.
> >
> > We could create a framework to automatically expose a basic nodetool
> > getter/setter command whenever a new virtual table is added, making the
> new
> > feature visible to non-power nodetool users while requiring little
> > additional effort from the VirtualTable implementor.
> >
> > When migrating commands from JMX to VirtualTables we could just update
> the
> > legacy nodetool command implementation to access the virtual table via
> the
> > generic StorageServiceMBean.queryVirtualTable(String name) method while
> > keeping the output consistent with the previous implementation, and
> > deprecating their JMX counterpart.
> >
> > Ultimately when all commands are migrated from JMX to VirtualTables we
> > could decide if we want to keep the nodetool CLI, acessing all virtual
> > tables via the generic JMX virtual table accessor, or to deprecate
> nodetool
> > altogether and tell users to query virtual tables directly via cqlsh
> > instead.
> >
> > Em qui., 15 de jul. de 2021 às 10:34, Paulo Motta <
> > pauloricardomg@gmail.com>
> > escreveu:
> >
> > > Thanks for bringing this discussion Benjamin. I raised a similar point
> in
> > > CASSANDRA-16725 <https://issues.apache.org/jira/browse/CASSANDRA-16725
> >
> > > and it may become a recurrent topic now the code freeze is lifted and
> > more
> > > contributors will want to add new administrative commands to nodetool
> so
> > > it's important that we discuss and decide a consistent approach to this
> > > transition moving forward.
> > >
> > > I was planning to write a CEP to propose a migration strategy from JMX
> to
> > > Virtual tables but since this discussion came before I will detail my
> > > thoughts so far.
> > >
> > > I think that we should add new commands exclusively to Virtual Tables
> and
> > > progressively migrate existing nodetool/JMX commands to
> VirtualTables/CQL
> > > until we ultimately get rid of JMX/nodetool. Nevertheless, from the
> user
> > > point of view it may be inconvenient/confusing to have administrative
> > > commands split between different interfaces so we need to think about
> > this
> > > transition carefully to provide the best possible user experience.
> > >
> > > My motivation for CASSANDRA-16513 <
> > > https://issues.apache.org/jira/browse/CASSANDRA-16513> was that we're
> > > already providing some functionalities exclusively via Virtual Tables,
> so
> > > these features may not be visible to non-power users which are
> accustomed
> > > to the nodetool CLI interface for admin commands. The original plan for
> > > that ticket was to make nodetool abstract away the underlying interface
> > > (JMX, CQL) for administrative commands, so we would expose admin
> > > functionality via the same CLI interface (nodetool) to users while
> > > progressively migrating the backend from JMX to CQL/VirtualTables.
> > >
> > > Some people raised the concern that this could cause confusion among
> > users
> > > about which credentials to use if JMX or CQL for nodetool. Based on
> this
> > > feedback I adapted the proposal to create an entirely different
> > > administrative CLI tool (which I called admintool) to access/modify
> > virtual
> > > tables. In this proposal new administrative commands would be added
> > > exclusively to Virtual Tables and would automatically land on this
> tool,
> > > and legacy nodetool commands (via JMX) would be progressively migrated
> to
> > > admintool (CQL/VT) until the migration is completed. The drawback of
> this
> > > alternative proposal is that it would still split administrative
> commands
> > > between different CLI tools.
> > >
> > > So, if we decide to stop adding new admin functionality to JMX we have
> a
> > > few options to make this transition smoother for our users:
> > > 1) Do nothing and tell users some admin functionalities will be
> > accessible
> > > exclusively via cqlsh/virtual tables - imo this option is the least
> > > user-friendly.
> > > 2) Make nodetool hybrid and provide a consistent interface to users
> while
> > > abstracting away the backend (JMX/CQL)
> > > 3) Create a new CLI tool (admintool) to provide CLI access to virtual
> > > tables and tell users to use both nodetool and admintool.
> > >
> > > I personally think option 2 is the least disruptive to users during the
> > > transition phase since people are already used to using nodetool so we
> > can
> > > provide a seamless transition to JMX while keeping the CLI tool for
> > legacy
> > > users. Even though there are concerns of confusion of which credentials
> > to
> > > use on nodetool if we support both interfaces, we can make sure this is
> > > well documented.
> > >
> > > Em qui., 15 de jul. de 2021 às 09:35, Benjamin Lerer <
> blerer@apache.org>
> > > escreveu:
> > >
> > >> Hi everyone,
> > >>
> > >> When Virtual Tables/System Views were introduced in 4.0 it was with
> the
> > >> intention to provide a more friendly way than JMX and NodeTool to
> manage
> > >> and monitor nodes.
> > >>
> > >> In CASSANDRA-16404 <
> > https://issues.apache.org/jira/browse/CASSANDRA-16404
> > >> >,
> > >> Sam raises the point that it might make sense from now on to stop
> adding
> > >> functionalities to NodeTool and to provide them through Virtual
> Tables.
> > >> My initial feeling was that we could provide both until we decided to
> > >> deprecate NodeTool but that would require some extra work and as such
> > >> might
> > >> not be a good strategy.
> > >>
> > >> What is your opinion on this?
> > >>
> > >
> >
>
Re: [DISCUSS] Virtual Tables and the future of NodeTool/JMX
Posted by Lorina Poland <lo...@datastax.com>.
I think it is important to keep in mind that users may be utilizing
nodetool programmatically, in scripts. Obviously, those scripts could use
calls to cqlsh as an alternative, but I'm a fan of keeping nodetool intact,
building out virtual table capability, and then deprecating nodetool. In
other words, only deprecate/remove nodetool commands once a *whole*
replacement is available. And then deprecate slowly, perhaps with migration
help in the docs for nodetool -> virtual tables.
Lorina
On Thu, Jul 15, 2021 at 6:59 AM Paulo Motta <pa...@gmail.com>
wrote:
> Perhaps one approach to expose VirtualTables via nodetool without requiring
> the user to provide CQL credentials would be to provide a generic
> StorageServiceMBean.queryVirtualTable(String name) JMX method returning a
> TabularData result. This would allow to keep a consistent nodetool frontend
> to users while progressively switching the backend from JMX to
> VirtualTables.
>
> We could create a framework to automatically expose a basic nodetool
> getter/setter command whenever a new virtual table is added, making the new
> feature visible to non-power nodetool users while requiring little
> additional effort from the VirtualTable implementor.
>
> When migrating commands from JMX to VirtualTables we could just update the
> legacy nodetool command implementation to access the virtual table via the
> generic StorageServiceMBean.queryVirtualTable(String name) method while
> keeping the output consistent with the previous implementation, and
> deprecating their JMX counterpart.
>
> Ultimately when all commands are migrated from JMX to VirtualTables we
> could decide if we want to keep the nodetool CLI, acessing all virtual
> tables via the generic JMX virtual table accessor, or to deprecate nodetool
> altogether and tell users to query virtual tables directly via cqlsh
> instead.
>
> Em qui., 15 de jul. de 2021 às 10:34, Paulo Motta <
> pauloricardomg@gmail.com>
> escreveu:
>
> > Thanks for bringing this discussion Benjamin. I raised a similar point in
> > CASSANDRA-16725 <https://issues.apache.org/jira/browse/CASSANDRA-16725>
> > and it may become a recurrent topic now the code freeze is lifted and
> more
> > contributors will want to add new administrative commands to nodetool so
> > it's important that we discuss and decide a consistent approach to this
> > transition moving forward.
> >
> > I was planning to write a CEP to propose a migration strategy from JMX to
> > Virtual tables but since this discussion came before I will detail my
> > thoughts so far.
> >
> > I think that we should add new commands exclusively to Virtual Tables and
> > progressively migrate existing nodetool/JMX commands to VirtualTables/CQL
> > until we ultimately get rid of JMX/nodetool. Nevertheless, from the user
> > point of view it may be inconvenient/confusing to have administrative
> > commands split between different interfaces so we need to think about
> this
> > transition carefully to provide the best possible user experience.
> >
> > My motivation for CASSANDRA-16513 <
> > https://issues.apache.org/jira/browse/CASSANDRA-16513> was that we're
> > already providing some functionalities exclusively via Virtual Tables, so
> > these features may not be visible to non-power users which are accustomed
> > to the nodetool CLI interface for admin commands. The original plan for
> > that ticket was to make nodetool abstract away the underlying interface
> > (JMX, CQL) for administrative commands, so we would expose admin
> > functionality via the same CLI interface (nodetool) to users while
> > progressively migrating the backend from JMX to CQL/VirtualTables.
> >
> > Some people raised the concern that this could cause confusion among
> users
> > about which credentials to use if JMX or CQL for nodetool. Based on this
> > feedback I adapted the proposal to create an entirely different
> > administrative CLI tool (which I called admintool) to access/modify
> virtual
> > tables. In this proposal new administrative commands would be added
> > exclusively to Virtual Tables and would automatically land on this tool,
> > and legacy nodetool commands (via JMX) would be progressively migrated to
> > admintool (CQL/VT) until the migration is completed. The drawback of this
> > alternative proposal is that it would still split administrative commands
> > between different CLI tools.
> >
> > So, if we decide to stop adding new admin functionality to JMX we have a
> > few options to make this transition smoother for our users:
> > 1) Do nothing and tell users some admin functionalities will be
> accessible
> > exclusively via cqlsh/virtual tables - imo this option is the least
> > user-friendly.
> > 2) Make nodetool hybrid and provide a consistent interface to users while
> > abstracting away the backend (JMX/CQL)
> > 3) Create a new CLI tool (admintool) to provide CLI access to virtual
> > tables and tell users to use both nodetool and admintool.
> >
> > I personally think option 2 is the least disruptive to users during the
> > transition phase since people are already used to using nodetool so we
> can
> > provide a seamless transition to JMX while keeping the CLI tool for
> legacy
> > users. Even though there are concerns of confusion of which credentials
> to
> > use on nodetool if we support both interfaces, we can make sure this is
> > well documented.
> >
> > Em qui., 15 de jul. de 2021 às 09:35, Benjamin Lerer <bl...@apache.org>
> > escreveu:
> >
> >> Hi everyone,
> >>
> >> When Virtual Tables/System Views were introduced in 4.0 it was with the
> >> intention to provide a more friendly way than JMX and NodeTool to manage
> >> and monitor nodes.
> >>
> >> In CASSANDRA-16404 <
> https://issues.apache.org/jira/browse/CASSANDRA-16404
> >> >,
> >> Sam raises the point that it might make sense from now on to stop adding
> >> functionalities to NodeTool and to provide them through Virtual Tables.
> >> My initial feeling was that we could provide both until we decided to
> >> deprecate NodeTool but that would require some extra work and as such
> >> might
> >> not be a good strategy.
> >>
> >> What is your opinion on this?
> >>
> >
>
Re: [DISCUSS] Virtual Tables and the future of NodeTool/JMX
Posted by Paulo Motta <pa...@gmail.com>.
Perhaps one approach to expose VirtualTables via nodetool without requiring
the user to provide CQL credentials would be to provide a generic
StorageServiceMBean.queryVirtualTable(String name) JMX method returning a
TabularData result. This would allow to keep a consistent nodetool frontend
to users while progressively switching the backend from JMX to
VirtualTables.
We could create a framework to automatically expose a basic nodetool
getter/setter command whenever a new virtual table is added, making the new
feature visible to non-power nodetool users while requiring little
additional effort from the VirtualTable implementor.
When migrating commands from JMX to VirtualTables we could just update the
legacy nodetool command implementation to access the virtual table via the
generic StorageServiceMBean.queryVirtualTable(String name) method while
keeping the output consistent with the previous implementation, and
deprecating their JMX counterpart.
Ultimately when all commands are migrated from JMX to VirtualTables we
could decide if we want to keep the nodetool CLI, acessing all virtual
tables via the generic JMX virtual table accessor, or to deprecate nodetool
altogether and tell users to query virtual tables directly via cqlsh
instead.
Em qui., 15 de jul. de 2021 às 10:34, Paulo Motta <pa...@gmail.com>
escreveu:
> Thanks for bringing this discussion Benjamin. I raised a similar point in
> CASSANDRA-16725 <https://issues.apache.org/jira/browse/CASSANDRA-16725>
> and it may become a recurrent topic now the code freeze is lifted and more
> contributors will want to add new administrative commands to nodetool so
> it's important that we discuss and decide a consistent approach to this
> transition moving forward.
>
> I was planning to write a CEP to propose a migration strategy from JMX to
> Virtual tables but since this discussion came before I will detail my
> thoughts so far.
>
> I think that we should add new commands exclusively to Virtual Tables and
> progressively migrate existing nodetool/JMX commands to VirtualTables/CQL
> until we ultimately get rid of JMX/nodetool. Nevertheless, from the user
> point of view it may be inconvenient/confusing to have administrative
> commands split between different interfaces so we need to think about this
> transition carefully to provide the best possible user experience.
>
> My motivation for CASSANDRA-16513 <
> https://issues.apache.org/jira/browse/CASSANDRA-16513> was that we're
> already providing some functionalities exclusively via Virtual Tables, so
> these features may not be visible to non-power users which are accustomed
> to the nodetool CLI interface for admin commands. The original plan for
> that ticket was to make nodetool abstract away the underlying interface
> (JMX, CQL) for administrative commands, so we would expose admin
> functionality via the same CLI interface (nodetool) to users while
> progressively migrating the backend from JMX to CQL/VirtualTables.
>
> Some people raised the concern that this could cause confusion among users
> about which credentials to use if JMX or CQL for nodetool. Based on this
> feedback I adapted the proposal to create an entirely different
> administrative CLI tool (which I called admintool) to access/modify virtual
> tables. In this proposal new administrative commands would be added
> exclusively to Virtual Tables and would automatically land on this tool,
> and legacy nodetool commands (via JMX) would be progressively migrated to
> admintool (CQL/VT) until the migration is completed. The drawback of this
> alternative proposal is that it would still split administrative commands
> between different CLI tools.
>
> So, if we decide to stop adding new admin functionality to JMX we have a
> few options to make this transition smoother for our users:
> 1) Do nothing and tell users some admin functionalities will be accessible
> exclusively via cqlsh/virtual tables - imo this option is the least
> user-friendly.
> 2) Make nodetool hybrid and provide a consistent interface to users while
> abstracting away the backend (JMX/CQL)
> 3) Create a new CLI tool (admintool) to provide CLI access to virtual
> tables and tell users to use both nodetool and admintool.
>
> I personally think option 2 is the least disruptive to users during the
> transition phase since people are already used to using nodetool so we can
> provide a seamless transition to JMX while keeping the CLI tool for legacy
> users. Even though there are concerns of confusion of which credentials to
> use on nodetool if we support both interfaces, we can make sure this is
> well documented.
>
> Em qui., 15 de jul. de 2021 às 09:35, Benjamin Lerer <bl...@apache.org>
> escreveu:
>
>> Hi everyone,
>>
>> When Virtual Tables/System Views were introduced in 4.0 it was with the
>> intention to provide a more friendly way than JMX and NodeTool to manage
>> and monitor nodes.
>>
>> In CASSANDRA-16404 <https://issues.apache.org/jira/browse/CASSANDRA-16404
>> >,
>> Sam raises the point that it might make sense from now on to stop adding
>> functionalities to NodeTool and to provide them through Virtual Tables.
>> My initial feeling was that we could provide both until we decided to
>> deprecate NodeTool but that would require some extra work and as such
>> might
>> not be a good strategy.
>>
>> What is your opinion on this?
>>
>
Re: [DISCUSS] Virtual Tables and the future of NodeTool/JMX
Posted by Paulo Motta <pa...@gmail.com>.
Thanks for bringing this discussion Benjamin. I raised a similar point in
CASSANDRA-16725 <https://issues.apache.org/jira/browse/CASSANDRA-16725> and
it may become a recurrent topic now the code freeze is lifted and more
contributors will want to add new administrative commands to nodetool so
it's important that we discuss and decide a consistent approach to this
transition moving forward.
I was planning to write a CEP to propose a migration strategy from JMX to
Virtual tables but since this discussion came before I will detail my
thoughts so far.
I think that we should add new commands exclusively to Virtual Tables and
progressively migrate existing nodetool/JMX commands to VirtualTables/CQL
until we ultimately get rid of JMX/nodetool. Nevertheless, from the user
point of view it may be inconvenient/confusing to have administrative
commands split between different interfaces so we need to think about this
transition carefully to provide the best possible user experience.
My motivation for CASSANDRA-16513 <
https://issues.apache.org/jira/browse/CASSANDRA-16513> was that we're
already providing some functionalities exclusively via Virtual Tables, so
these features may not be visible to non-power users which are accustomed
to the nodetool CLI interface for admin commands. The original plan for
that ticket was to make nodetool abstract away the underlying interface
(JMX, CQL) for administrative commands, so we would expose admin
functionality via the same CLI interface (nodetool) to users while
progressively migrating the backend from JMX to CQL/VirtualTables.
Some people raised the concern that this could cause confusion among users
about which credentials to use if JMX or CQL for nodetool. Based on this
feedback I adapted the proposal to create an entirely different
administrative CLI tool (which I called admintool) to access/modify virtual
tables. In this proposal new administrative commands would be added
exclusively to Virtual Tables and would automatically land on this tool,
and legacy nodetool commands (via JMX) would be progressively migrated to
admintool (CQL/VT) until the migration is completed. The drawback of this
alternative proposal is that it would still split administrative commands
between different CLI tools.
So, if we decide to stop adding new admin functionality to JMX we have a
few options to make this transition smoother for our users:
1) Do nothing and tell users some admin functionalities will be accessible
exclusively via cqlsh/virtual tables - imo this option is the least
user-friendly.
2) Make nodetool hybrid and provide a consistent interface to users while
abstracting away the backend (JMX/CQL)
3) Create a new CLI tool (admintool) to provide CLI access to virtual
tables and tell users to use both nodetool and admintool.
I personally think option 2 is the least disruptive to users during the
transition phase since people are already used to using nodetool so we can
provide a seamless transition to JMX while keeping the CLI tool for legacy
users. Even though there are concerns of confusion of which credentials to
use on nodetool if we support both interfaces, we can make sure this is
well documented.
Em qui., 15 de jul. de 2021 às 09:35, Benjamin Lerer <bl...@apache.org>
escreveu:
> Hi everyone,
>
> When Virtual Tables/System Views were introduced in 4.0 it was with the
> intention to provide a more friendly way than JMX and NodeTool to manage
> and monitor nodes.
>
> In CASSANDRA-16404 <https://issues.apache.org/jira/browse/CASSANDRA-16404
> >,
> Sam raises the point that it might make sense from now on to stop adding
> functionalities to NodeTool and to provide them through Virtual Tables.
> My initial feeling was that we could provide both until we decided to
> deprecate NodeTool but that would require some extra work and as such might
> not be a good strategy.
>
> What is your opinion on this?
>
Re: [DISCUSS] Virtual Tables and the future of NodeTool/JMX
Posted by Brandon Williams <dr...@gmail.com>.
On Thu, Jul 15, 2021 at 8:09 AM Stefan Miklosovic
<st...@instaclustr.com> wrote:
> Hence what I would like to do is to add 16725 as the last command ever
> in nodetool and after that we might just make a big fat line and we
> might slowly transition to a new system on virtual tables.
I would really like to avoid the situation where you may need both to
accomplish what you need to do. If there are more things to add later,
we should do that to keep nodetool viable as a standalone
administration tool until virtual tables have functional parity.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
For additional commands, e-mail: dev-help@cassandra.apache.org
Re: [DISCUSS] Virtual Tables and the future of NodeTool/JMX
Posted by Stefan Miklosovic <st...@instaclustr.com>.
Hi Benjamin,
I was discussing this closely with Paulo some time ago, you may have
already read the other email about this topic when I was talking about
what we wanted to do with a GSOC student. I just can not find it for
now ...
In general I agree that we might slowly drift away from nodetool but
one particular command I am working on right now is CASSANDRA-16725.
It is done, I am just polishing tests but it is in general good to go.
There is currently not any way to actually see how audit logging is
configured (except looking into cassandra.yaml but after you disable /
enable it with a different configuration, I am not sure of any way to
check this in runtime which is quite absurd).
Hence what I would like to do is to add 16725 as the last command ever
in nodetool and after that we might just make a big fat line and we
might slowly transition to a new system on virtual tables.
The primary reason I want to finish 16725 is that, let's not kid
ourselves, it will take another half of year to have something usable
(and released!) on this front and until then we will not be able to
check how, for example, audit logging is configured, just because we
find ourselves in implementing some "framework" around virtual tables
stuff and CLI tooling for that. We should go after user experience and
functionality first - not building some ivory towers where we spend a
lot of time inventing something while leaving a user behind -
functionality-wise, because we just have to do it differently.
I do not think of any other nodetool command we need to add after
16725 so let me finish that and then we can go wild.
Regards
On Thu, 15 Jul 2021 at 14:34, Benjamin Lerer <bl...@apache.org> wrote:
>
> Hi everyone,
>
> When Virtual Tables/System Views were introduced in 4.0 it was with the
> intention to provide a more friendly way than JMX and NodeTool to manage
> and monitor nodes.
>
> In CASSANDRA-16404 <https://issues.apache.org/jira/browse/CASSANDRA-16404>,
> Sam raises the point that it might make sense from now on to stop adding
> functionalities to NodeTool and to provide them through Virtual Tables.
> My initial feeling was that we could provide both until we decided to
> deprecate NodeTool but that would require some extra work and as such might
> not be a good strategy.
>
> What is your opinion on this?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
For additional commands, e-mail: dev-help@cassandra.apache.org
Re: [DISCUSS] Virtual Tables and the future of NodeTool/JMX
Posted by Paulo Motta <pa...@gmail.com>.
> Can be accomplished by updating or inserting on the settings virtual
table via UPDATE system_views.settings SET value = 32 WHERE name =
'compaction_throughput';
Oh nice, I wasn't aware this was available already, this is a great feature
to look forward to in 4.0!
> 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
Thanks for the pointer Chris. Will put together a proposal based on input
from this thread with a long term plan to slowly transition from JMX to
virtual tables.
<https://issues.apache.org/jira/browse/CASSANDRA-14629>
Em seg., 19 de jul. de 2021 às 12:33, Chris Lohfink <cl...@gmail.com>
escreveu:
> > 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 <al...@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.miklosovic@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....@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 <mc...@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-unsubscribe@cassandra.apache.org
> > > For additional commands, e-mail: dev-help@cassandra.apache.org
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> > For additional commands, e-mail: dev-help@cassandra.apache.org
> >
> >
>
Re: [DISCUSS] Virtual Tables and the future of NodeTool/JMX
Posted by Chris Lohfink <cl...@gmail.com>.
> 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 <al...@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.miklosovic@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....@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 <mc...@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-unsubscribe@cassandra.apache.org
> > For additional commands, e-mail: dev-help@cassandra.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> For additional commands, e-mail: dev-help@cassandra.apache.org
>
>
Re: [DISCUSS] Virtual Tables and the future of NodeTool/JMX
Posted by Aleksey Yeschenko <al...@apache.org>.
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 <st...@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....@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 <mc...@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-unsubscribe@cassandra.apache.org
> For additional commands, e-mail: dev-help@cassandra.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
For additional commands, e-mail: dev-help@cassandra.apache.org
Re: [DISCUSS] Virtual Tables and the future of NodeTool/JMX
Posted by Stefan Miklosovic <st...@instaclustr.com>.
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....@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 <mc...@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-unsubscribe@cassandra.apache.org
For additional commands, e-mail: dev-help@cassandra.apache.org
Re: [DISCUSS] Virtual Tables and the future of NodeTool/JMX
Posted by Paulo Motta <pa...@gmail.com>.
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 <bl...@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 <pa...@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....@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 <mc...@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!)
> > > >
> > >
> >
>
Re: [DISCUSS] Virtual Tables and the future of NodeTool/JMX
Posted by Benjamin Lerer <bl...@apache.org>.
>
> 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 <pa...@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....@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 <mc...@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!)
> > >
> >
>
Re: [DISCUSS] Virtual Tables and the future of NodeTool/JMX
Posted by Paulo Motta <pa...@gmail.com>.
> 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....@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 <mc...@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!)
> >
>
Re: [DISCUSS] Virtual Tables and the future of NodeTool/JMX
Posted by Benjamin Lerer <b....@gmail.com>.
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 <mc...@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!)
>
Re: [DISCUSS] Virtual Tables and the future of NodeTool/JMX
Posted by Mick Semb Wever <mc...@apache.org>.
>
> > 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!)
Re: [DISCUSS] Virtual Tables and the future of NodeTool/JMX
Posted by Paulo Motta <pa...@gmail.com>.
> You lost me at "without requiring the user to provide CQL credentials"
This is to address Jeremiah's concern of requiring users to provide
different sets of credentials (JMX, CQL) to use nodetool, which can be an
operational pain to users.
I fail to see what's your concern here, since this would not be a departure
from the current approach where the management/admin/monitoring interface
is exclusively protected by JMX authentication, which is more restrictive
than CQL, while still allowing access with CQL credentials via cqlsh or
driver.
> 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.
Em qui., 15 de jul. de 2021 às 18:14, Stefan Miklosovic <
stefan.miklosovic@instaclustr.com> escreveu:
> Thank you, I will proceed with my patch.
>
> On Thu, 15 Jul 2021 at 22:29, Jeff Jirsa <jj...@gmail.com> wrote:
> >
> > Agreed. Status quo is status quo. If someone wants to change status quo,
> > CEP would be appreciated.
> >
> > Until CEP exists and is approved, work on patches in flight seems
> > reasonable and valid.
> >
> >
> > On Thu, Jul 15, 2021 at 12:38 PM J. D. Jordan <jeremiah.jordan@gmail.com
> >
> > wrote:
> >
> > > I see no problem with continuing to add JMX commands for the
> foreseeable
> > > future.
> > >
> > > > On Jul 15, 2021, at 2:07 PM, Stefan Miklosovic <
> > > stefan.miklosovic@instaclustr.com> wrote:
> > > >
> > > > Can I have a clear response from you, community, if my work on 16725
> > > > is rendered totally useless in the light of this discussion? The time
> > > > on that was already spent and I honestly can not see why it would be
> a
> > > > problem to merge that command in.
> > > >
> > > > I am particularly objecting to Paulo's idea about dropping JMX
> command
> > > > implementations altogether, I find it quite radical without any
> > > > meaningful justification except "wasting somebody's time" but since
> it
> > > > is my time I spent on this, I am not sure why anybody would care?
> > > > While I do understand that we are trying to move forward with cql and
> > > > so on, I find it quite ridiculous to stop "5 minutes before 12" just
> > > > because somebody happened to drop an email to the dev list about this
> > > > before I managed to finish it.
> > > >
> > > > In other words, I find it just easier to finish it and voila, we can
> > > > query audit's config, when we are super close to it and all who spend
> > > > time on that was me - rather than waiting for weeks and months until
> > > > this discussion settles, living without that until then.
> > > >
> > > > Regards
> > > >
> > > >> On Thu, 15 Jul 2021 at 20:38, J. D. Jordan <
> jeremiah.jordan@gmail.com>
> > > wrote:
> > > >>
> > > >> I also am in favor of continuing to support nodetool in parallel
> with
> > > developing a command line tool and associated virtual tables to replace
> > > nodetool/JMX at some point in the future.
> > > >> I don’t think “native transport is not currently available during
> > > startup” is something to halt progress towards this goal. There are
> many
> > > ways to change the system to make that a non-problem. But it is
> something
> > > to remember while moving towards the goal of node management without
> using
> > > JMX.
> > > >>
> > > >> -Jeremiah
> > > >>
> > > >>>> On Jul 15, 2021, at 12:21 PM, Mick Semb Wever <mc...@apache.org>
> wrote:
> > > >>>
> > > >>>
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>> What is your opinion on this?
> > > >>>>
> > > >>>
> > > >>>
> > > >>> This discussion was touched when implementing Diagnostics Events,
> at
> > > least
> > > >>> the discussion of JMX vs native (rather than nodetool vs cqlsh).
> At
> > > that
> > > >>> time JMX was chosen because there was no way for a client to
> specify
> > > the
> > > >>> host you wanted the information from. Some more info in
> CASSANDRA-13459
> > > >>> and CASSANDRA-13472.
> > > >>>
> > > >>> The java and python drivers have since added this functionality.
> But if
> > > >>> it's not widely adopted by all the drivers, and the functionality
> may
> > > have
> > > >>> programmatic uses, this can be problematic.
> > > >>
> > > >>
> ---------------------------------------------------------------------
> > > >> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> > > >> For additional commands, e-mail: dev-help@cassandra.apache.org
> > > >>
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> > > > For additional commands, e-mail: dev-help@cassandra.apache.org
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> > > For additional commands, e-mail: dev-help@cassandra.apache.org
> > >
> > >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> For additional commands, e-mail: dev-help@cassandra.apache.org
>
>
Re: [DISCUSS] Virtual Tables and the future of NodeTool/JMX
Posted by Stefan Miklosovic <st...@instaclustr.com>.
Thank you, I will proceed with my patch.
On Thu, 15 Jul 2021 at 22:29, Jeff Jirsa <jj...@gmail.com> wrote:
>
> Agreed. Status quo is status quo. If someone wants to change status quo,
> CEP would be appreciated.
>
> Until CEP exists and is approved, work on patches in flight seems
> reasonable and valid.
>
>
> On Thu, Jul 15, 2021 at 12:38 PM J. D. Jordan <je...@gmail.com>
> wrote:
>
> > I see no problem with continuing to add JMX commands for the foreseeable
> > future.
> >
> > > On Jul 15, 2021, at 2:07 PM, Stefan Miklosovic <
> > stefan.miklosovic@instaclustr.com> wrote:
> > >
> > > Can I have a clear response from you, community, if my work on 16725
> > > is rendered totally useless in the light of this discussion? The time
> > > on that was already spent and I honestly can not see why it would be a
> > > problem to merge that command in.
> > >
> > > I am particularly objecting to Paulo's idea about dropping JMX command
> > > implementations altogether, I find it quite radical without any
> > > meaningful justification except "wasting somebody's time" but since it
> > > is my time I spent on this, I am not sure why anybody would care?
> > > While I do understand that we are trying to move forward with cql and
> > > so on, I find it quite ridiculous to stop "5 minutes before 12" just
> > > because somebody happened to drop an email to the dev list about this
> > > before I managed to finish it.
> > >
> > > In other words, I find it just easier to finish it and voila, we can
> > > query audit's config, when we are super close to it and all who spend
> > > time on that was me - rather than waiting for weeks and months until
> > > this discussion settles, living without that until then.
> > >
> > > Regards
> > >
> > >> On Thu, 15 Jul 2021 at 20:38, J. D. Jordan <je...@gmail.com>
> > wrote:
> > >>
> > >> I also am in favor of continuing to support nodetool in parallel with
> > developing a command line tool and associated virtual tables to replace
> > nodetool/JMX at some point in the future.
> > >> I don’t think “native transport is not currently available during
> > startup” is something to halt progress towards this goal. There are many
> > ways to change the system to make that a non-problem. But it is something
> > to remember while moving towards the goal of node management without using
> > JMX.
> > >>
> > >> -Jeremiah
> > >>
> > >>>> On Jul 15, 2021, at 12:21 PM, Mick Semb Wever <mc...@apache.org> wrote:
> > >>>
> > >>>
> > >>>>
> > >>>>
> > >>>>
> > >>>> What is your opinion on this?
> > >>>>
> > >>>
> > >>>
> > >>> This discussion was touched when implementing Diagnostics Events, at
> > least
> > >>> the discussion of JMX vs native (rather than nodetool vs cqlsh). At
> > that
> > >>> time JMX was chosen because there was no way for a client to specify
> > the
> > >>> host you wanted the information from. Some more info in CASSANDRA-13459
> > >>> and CASSANDRA-13472.
> > >>>
> > >>> The java and python drivers have since added this functionality. But if
> > >>> it's not widely adopted by all the drivers, and the functionality may
> > have
> > >>> programmatic uses, this can be problematic.
> > >>
> > >> ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> > >> For additional commands, e-mail: dev-help@cassandra.apache.org
> > >>
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> > > For additional commands, e-mail: dev-help@cassandra.apache.org
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> > For additional commands, e-mail: dev-help@cassandra.apache.org
> >
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
For additional commands, e-mail: dev-help@cassandra.apache.org
Re: [DISCUSS] Virtual Tables and the future of NodeTool/JMX
Posted by Jeff Jirsa <jj...@gmail.com>.
Agreed. Status quo is status quo. If someone wants to change status quo,
CEP would be appreciated.
Until CEP exists and is approved, work on patches in flight seems
reasonable and valid.
On Thu, Jul 15, 2021 at 12:38 PM J. D. Jordan <je...@gmail.com>
wrote:
> I see no problem with continuing to add JMX commands for the foreseeable
> future.
>
> > On Jul 15, 2021, at 2:07 PM, Stefan Miklosovic <
> stefan.miklosovic@instaclustr.com> wrote:
> >
> > Can I have a clear response from you, community, if my work on 16725
> > is rendered totally useless in the light of this discussion? The time
> > on that was already spent and I honestly can not see why it would be a
> > problem to merge that command in.
> >
> > I am particularly objecting to Paulo's idea about dropping JMX command
> > implementations altogether, I find it quite radical without any
> > meaningful justification except "wasting somebody's time" but since it
> > is my time I spent on this, I am not sure why anybody would care?
> > While I do understand that we are trying to move forward with cql and
> > so on, I find it quite ridiculous to stop "5 minutes before 12" just
> > because somebody happened to drop an email to the dev list about this
> > before I managed to finish it.
> >
> > In other words, I find it just easier to finish it and voila, we can
> > query audit's config, when we are super close to it and all who spend
> > time on that was me - rather than waiting for weeks and months until
> > this discussion settles, living without that until then.
> >
> > Regards
> >
> >> On Thu, 15 Jul 2021 at 20:38, J. D. Jordan <je...@gmail.com>
> wrote:
> >>
> >> I also am in favor of continuing to support nodetool in parallel with
> developing a command line tool and associated virtual tables to replace
> nodetool/JMX at some point in the future.
> >> I don’t think “native transport is not currently available during
> startup” is something to halt progress towards this goal. There are many
> ways to change the system to make that a non-problem. But it is something
> to remember while moving towards the goal of node management without using
> JMX.
> >>
> >> -Jeremiah
> >>
> >>>> On Jul 15, 2021, at 12:21 PM, Mick Semb Wever <mc...@apache.org> wrote:
> >>>
> >>>
> >>>>
> >>>>
> >>>>
> >>>> What is your opinion on this?
> >>>>
> >>>
> >>>
> >>> This discussion was touched when implementing Diagnostics Events, at
> least
> >>> the discussion of JMX vs native (rather than nodetool vs cqlsh). At
> that
> >>> time JMX was chosen because there was no way for a client to specify
> the
> >>> host you wanted the information from. Some more info in CASSANDRA-13459
> >>> and CASSANDRA-13472.
> >>>
> >>> The java and python drivers have since added this functionality. But if
> >>> it's not widely adopted by all the drivers, and the functionality may
> have
> >>> programmatic uses, this can be problematic.
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> >> For additional commands, e-mail: dev-help@cassandra.apache.org
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> > For additional commands, e-mail: dev-help@cassandra.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> For additional commands, e-mail: dev-help@cassandra.apache.org
>
>
Re: [DISCUSS] Virtual Tables and the future of NodeTool/JMX
Posted by "J. D. Jordan" <je...@gmail.com>.
I see no problem with continuing to add JMX commands for the foreseeable future.
> On Jul 15, 2021, at 2:07 PM, Stefan Miklosovic <st...@instaclustr.com> wrote:
>
> Can I have a clear response from you, community, if my work on 16725
> is rendered totally useless in the light of this discussion? The time
> on that was already spent and I honestly can not see why it would be a
> problem to merge that command in.
>
> I am particularly objecting to Paulo's idea about dropping JMX command
> implementations altogether, I find it quite radical without any
> meaningful justification except "wasting somebody's time" but since it
> is my time I spent on this, I am not sure why anybody would care?
> While I do understand that we are trying to move forward with cql and
> so on, I find it quite ridiculous to stop "5 minutes before 12" just
> because somebody happened to drop an email to the dev list about this
> before I managed to finish it.
>
> In other words, I find it just easier to finish it and voila, we can
> query audit's config, when we are super close to it and all who spend
> time on that was me - rather than waiting for weeks and months until
> this discussion settles, living without that until then.
>
> Regards
>
>> On Thu, 15 Jul 2021 at 20:38, J. D. Jordan <je...@gmail.com> wrote:
>>
>> I also am in favor of continuing to support nodetool in parallel with developing a command line tool and associated virtual tables to replace nodetool/JMX at some point in the future.
>> I don’t think “native transport is not currently available during startup” is something to halt progress towards this goal. There are many ways to change the system to make that a non-problem. But it is something to remember while moving towards the goal of node management without using JMX.
>>
>> -Jeremiah
>>
>>>> On Jul 15, 2021, at 12:21 PM, Mick Semb Wever <mc...@apache.org> wrote:
>>>
>>>
>>>>
>>>>
>>>>
>>>> What is your opinion on this?
>>>>
>>>
>>>
>>> This discussion was touched when implementing Diagnostics Events, at least
>>> the discussion of JMX vs native (rather than nodetool vs cqlsh). At that
>>> time JMX was chosen because there was no way for a client to specify the
>>> host you wanted the information from. Some more info in CASSANDRA-13459
>>> and CASSANDRA-13472.
>>>
>>> The java and python drivers have since added this functionality. But if
>>> it's not widely adopted by all the drivers, and the functionality may have
>>> programmatic uses, this can be problematic.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
>> For additional commands, e-mail: dev-help@cassandra.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> For additional commands, e-mail: dev-help@cassandra.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
For additional commands, e-mail: dev-help@cassandra.apache.org
Re: [DISCUSS] Virtual Tables and the future of NodeTool/JMX
Posted by Paulo Motta <pa...@gmail.com>.
> I see no problem with continuing to add JMX commands for the foreseeable
future.
From what I understood, Sam's proposal, to which I agree, is to entirely
avoid adding new functionality to the JMX interface moving forward but just
to VirtualTables, in order to avoid requiring new functionality to be added
to both JMX and VirtualTable interfaces, creating user confusion,
additional development burden and adding code we know it's going to be
deprecated.
I think we should first focus on deciding if we want to go through this
path, before deciding what to do with in-progress JMX work such as
Cassandra-16404 and CASSANDRA-16725.
> This is coming from the "JMX needs to die in a fire" guy, but I think
Nodetool needs to stay as-is in 4.x.
I don't think anybody is in favor of removing nodetool in 4.X. Please note
that stopping adding new functionality to JMX does not mean killing
nodetool. The transition proposal is:
1) Stop adding new stuff to JMX
2) Add new admin commands only to VirtualTables while exposing them via
nodetool
3) Progressively migrate nodetool commands to virtual tables
4) Once all nodetool commands are migrated to virtual tables, in the next
major, consider deprecating nodetool in a separate effort.
> Also, this should probably be a CEP.
I layed out on this thread a sketch transition proposal to keep the
nodetool frontend unchanged while replacing it's backend progressively with
VirtualTable, with zero user impact and would love to detail this into a
CEP if there's community interest/support.
Em qui., 15 de jul. de 2021 às 16:40, Patrick McFadin <pm...@gmail.com>
escreveu:
> This is coming from the "JMX needs to die in a fire" guy, but I think
> Nodetool needs to stay as-is in 4.x. This is a massive breaking change for
> operators which fits into the major version issue requirements.
>
> Also, this should probably be a CEP.
>
> Patrick
>
> On Thu, Jul 15, 2021 at 12:07 PM Stefan Miklosovic <
> stefan.miklosovic@instaclustr.com> wrote:
>
> > Can I have a clear response from you, community, if my work on 16725
> > is rendered totally useless in the light of this discussion? The time
> > on that was already spent and I honestly can not see why it would be a
> > problem to merge that command in.
> >
> > I am particularly objecting to Paulo's idea about dropping JMX command
> > implementations altogether, I find it quite radical without any
> > meaningful justification except "wasting somebody's time" but since it
> > is my time I spent on this, I am not sure why anybody would care?
> > While I do understand that we are trying to move forward with cql and
> > so on, I find it quite ridiculous to stop "5 minutes before 12" just
> > because somebody happened to drop an email to the dev list about this
> > before I managed to finish it.
> >
> > In other words, I find it just easier to finish it and voila, we can
> > query audit's config, when we are super close to it and all who spend
> > time on that was me - rather than waiting for weeks and months until
> > this discussion settles, living without that until then.
> >
> > Regards
> >
> > On Thu, 15 Jul 2021 at 20:38, J. D. Jordan <je...@gmail.com>
> > wrote:
> > >
> > > I also am in favor of continuing to support nodetool in parallel with
> > developing a command line tool and associated virtual tables to replace
> > nodetool/JMX at some point in the future.
> > > I don’t think “native transport is not currently available during
> > startup” is something to halt progress towards this goal. There are many
> > ways to change the system to make that a non-problem. But it is
> something
> > to remember while moving towards the goal of node management without
> using
> > JMX.
> > >
> > > -Jeremiah
> > >
> > > > On Jul 15, 2021, at 12:21 PM, Mick Semb Wever <mc...@apache.org>
> wrote:
> > > >
> > > >
> > > >>
> > > >>
> > > >>
> > > >> What is your opinion on this?
> > > >>
> > > >
> > > >
> > > > This discussion was touched when implementing Diagnostics Events, at
> > least
> > > > the discussion of JMX vs native (rather than nodetool vs cqlsh). At
> > that
> > > > time JMX was chosen because there was no way for a client to specify
> > the
> > > > host you wanted the information from. Some more info in
> CASSANDRA-13459
> > > > and CASSANDRA-13472.
> > > >
> > > > The java and python drivers have since added this functionality. But
> if
> > > > it's not widely adopted by all the drivers, and the functionality may
> > have
> > > > programmatic uses, this can be problematic.
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> > > For additional commands, e-mail: dev-help@cassandra.apache.org
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> > For additional commands, e-mail: dev-help@cassandra.apache.org
> >
> >
>
Re: [DISCUSS] Virtual Tables and the future of NodeTool/JMX
Posted by Patrick McFadin <pm...@gmail.com>.
This is coming from the "JMX needs to die in a fire" guy, but I think
Nodetool needs to stay as-is in 4.x. This is a massive breaking change for
operators which fits into the major version issue requirements.
Also, this should probably be a CEP.
Patrick
On Thu, Jul 15, 2021 at 12:07 PM Stefan Miklosovic <
stefan.miklosovic@instaclustr.com> wrote:
> Can I have a clear response from you, community, if my work on 16725
> is rendered totally useless in the light of this discussion? The time
> on that was already spent and I honestly can not see why it would be a
> problem to merge that command in.
>
> I am particularly objecting to Paulo's idea about dropping JMX command
> implementations altogether, I find it quite radical without any
> meaningful justification except "wasting somebody's time" but since it
> is my time I spent on this, I am not sure why anybody would care?
> While I do understand that we are trying to move forward with cql and
> so on, I find it quite ridiculous to stop "5 minutes before 12" just
> because somebody happened to drop an email to the dev list about this
> before I managed to finish it.
>
> In other words, I find it just easier to finish it and voila, we can
> query audit's config, when we are super close to it and all who spend
> time on that was me - rather than waiting for weeks and months until
> this discussion settles, living without that until then.
>
> Regards
>
> On Thu, 15 Jul 2021 at 20:38, J. D. Jordan <je...@gmail.com>
> wrote:
> >
> > I also am in favor of continuing to support nodetool in parallel with
> developing a command line tool and associated virtual tables to replace
> nodetool/JMX at some point in the future.
> > I don’t think “native transport is not currently available during
> startup” is something to halt progress towards this goal. There are many
> ways to change the system to make that a non-problem. But it is something
> to remember while moving towards the goal of node management without using
> JMX.
> >
> > -Jeremiah
> >
> > > On Jul 15, 2021, at 12:21 PM, Mick Semb Wever <mc...@apache.org> wrote:
> > >
> > >
> > >>
> > >>
> > >>
> > >> What is your opinion on this?
> > >>
> > >
> > >
> > > This discussion was touched when implementing Diagnostics Events, at
> least
> > > the discussion of JMX vs native (rather than nodetool vs cqlsh). At
> that
> > > time JMX was chosen because there was no way for a client to specify
> the
> > > host you wanted the information from. Some more info in CASSANDRA-13459
> > > and CASSANDRA-13472.
> > >
> > > The java and python drivers have since added this functionality. But if
> > > it's not widely adopted by all the drivers, and the functionality may
> have
> > > programmatic uses, this can be problematic.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> > For additional commands, e-mail: dev-help@cassandra.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> For additional commands, e-mail: dev-help@cassandra.apache.org
>
>
Re: [DISCUSS] Virtual Tables and the future of NodeTool/JMX
Posted by Stefan Miklosovic <st...@instaclustr.com>.
Can I have a clear response from you, community, if my work on 16725
is rendered totally useless in the light of this discussion? The time
on that was already spent and I honestly can not see why it would be a
problem to merge that command in.
I am particularly objecting to Paulo's idea about dropping JMX command
implementations altogether, I find it quite radical without any
meaningful justification except "wasting somebody's time" but since it
is my time I spent on this, I am not sure why anybody would care?
While I do understand that we are trying to move forward with cql and
so on, I find it quite ridiculous to stop "5 minutes before 12" just
because somebody happened to drop an email to the dev list about this
before I managed to finish it.
In other words, I find it just easier to finish it and voila, we can
query audit's config, when we are super close to it and all who spend
time on that was me - rather than waiting for weeks and months until
this discussion settles, living without that until then.
Regards
On Thu, 15 Jul 2021 at 20:38, J. D. Jordan <je...@gmail.com> wrote:
>
> I also am in favor of continuing to support nodetool in parallel with developing a command line tool and associated virtual tables to replace nodetool/JMX at some point in the future.
> I don’t think “native transport is not currently available during startup” is something to halt progress towards this goal. There are many ways to change the system to make that a non-problem. But it is something to remember while moving towards the goal of node management without using JMX.
>
> -Jeremiah
>
> > On Jul 15, 2021, at 12:21 PM, Mick Semb Wever <mc...@apache.org> wrote:
> >
> >
> >>
> >>
> >>
> >> What is your opinion on this?
> >>
> >
> >
> > This discussion was touched when implementing Diagnostics Events, at least
> > the discussion of JMX vs native (rather than nodetool vs cqlsh). At that
> > time JMX was chosen because there was no way for a client to specify the
> > host you wanted the information from. Some more info in CASSANDRA-13459
> > and CASSANDRA-13472.
> >
> > The java and python drivers have since added this functionality. But if
> > it's not widely adopted by all the drivers, and the functionality may have
> > programmatic uses, this can be problematic.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> For additional commands, e-mail: dev-help@cassandra.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
For additional commands, e-mail: dev-help@cassandra.apache.org
Re: [DISCUSS] Virtual Tables and the future of NodeTool/JMX
Posted by "J. D. Jordan" <je...@gmail.com>.
I also am in favor of continuing to support nodetool in parallel with developing a command line tool and associated virtual tables to replace nodetool/JMX at some point in the future.
I don’t think “native transport is not currently available during startup” is something to halt progress towards this goal. There are many ways to change the system to make that a non-problem. But it is something to remember while moving towards the goal of node management without using JMX.
-Jeremiah
> On Jul 15, 2021, at 12:21 PM, Mick Semb Wever <mc...@apache.org> wrote:
>
>
>>
>>
>>
>> What is your opinion on this?
>>
>
>
> This discussion was touched when implementing Diagnostics Events, at least
> the discussion of JMX vs native (rather than nodetool vs cqlsh). At that
> time JMX was chosen because there was no way for a client to specify the
> host you wanted the information from. Some more info in CASSANDRA-13459
> and CASSANDRA-13472.
>
> The java and python drivers have since added this functionality. But if
> it's not widely adopted by all the drivers, and the functionality may have
> programmatic uses, this can be problematic.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
For additional commands, e-mail: dev-help@cassandra.apache.org
Re: [DISCUSS] Virtual Tables and the future of NodeTool/JMX
Posted by Mick Semb Wever <mc...@apache.org>.
>
>
> What is your opinion on this?
>
This discussion was touched when implementing Diagnostics Events, at least
the discussion of JMX vs native (rather than nodetool vs cqlsh). At that
time JMX was chosen because there was no way for a client to specify the
host you wanted the information from. Some more info in CASSANDRA-13459
and CASSANDRA-13472.
The java and python drivers have since added this functionality. But if
it's not widely adopted by all the drivers, and the functionality may have
programmatic uses, this can be problematic.