[jira] [Updated] (CASSANDRA-17905) Cassandra repo not updated with latest 4.0.6 package
[ https://issues.apache.org/jira/browse/CASSANDRA-17905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] deepa g updated CASSANDRA-17905: Description: Hi Team, The repo is not updated with latest package -[Index of /cassandra/redhat/40x (apache.org)|https://downloads.apache.org/cassandra/redhat/40x/] we are looking to download 4.0.6 from the above link but 4.0.5 package is getting downloaded this is the new version support - [Apache Cassandra | Apache Cassandra Documentation|https://cassandra.apache.org/_/blog/Apache-Cassandra-Changelog-18-August-2022.html] was: Hi Team, The repo is not updated with latest package -[Index of /cassandra/redhat/40x (apache.org)|https://downloads.apache.org/cassandra/redhat/40x/] we are looking to download 4.0.6 from the above link but 4.0.5 package is getting downloaded > Cassandra repo not updated with latest 4.0.6 package > > > Key: CASSANDRA-17905 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17905 > Project: Cassandra > Issue Type: Improvement >Reporter: deepa g >Priority: Normal > > Hi Team, > > The repo is not updated with latest package -[Index of /cassandra/redhat/40x > (apache.org)|https://downloads.apache.org/cassandra/redhat/40x/] > > we are looking to download 4.0.6 from the above link but 4.0.5 package is > getting downloaded > > this is the new version support - [Apache Cassandra | Apache Cassandra > Documentation|https://cassandra.apache.org/_/blog/Apache-Cassandra-Changelog-18-August-2022.html] -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-17905) Cassandra repo not updated with latest 4.0.6 package
deepa g created CASSANDRA-17905: --- Summary: Cassandra repo not updated with latest 4.0.6 package Key: CASSANDRA-17905 URL: https://issues.apache.org/jira/browse/CASSANDRA-17905 Project: Cassandra Issue Type: Improvement Reporter: deepa g Hi Team, The repo is not updated with latest package -[Index of /cassandra/redhat/40x (apache.org)|https://downloads.apache.org/cassandra/redhat/40x/] we are looking to download 4.0.6 from the above link but 4.0.5 package is getting downloaded -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15046) Add a "history" command to cqlsh. Perhaps "show history"?
[ https://issues.apache.org/jira/browse/CASSANDRA-15046?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yundi Chen updated CASSANDRA-15046: --- Status: In Progress (was: Patch Available) > Add a "history" command to cqlsh. Perhaps "show history"? > -- > > Key: CASSANDRA-15046 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15046 > Project: Cassandra > Issue Type: Improvement > Components: CQL/Interpreter >Reporter: Wes Peters >Assignee: Yundi Chen >Priority: Low > Labels: ghc-lhf, lhf > Fix For: 4.x > > > I was trying to capture some create key space and create table commands from > a running cqlsh, and found there was no equivalent to the '\s' history > command in Postgres' psql shell. It's a great tool for figuring out what you > were doing yesterday. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15046) Add a "history" command to cqlsh. Perhaps "show history"?
[
https://issues.apache.org/jira/browse/CASSANDRA-15046?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17606410#comment-17606410
]
Paulo Motta commented on CASSANDRA-15046:
-
Took an initial look, looks fine from a quick glance but haven't tested yet.
Can you add test to check that no more than {{$CQLSH_HISTSIZE=50}} entries are
displayed? The improvements can probably be done as separate tickets.
We will need to write to the development mailing list to see if anyone has any
feedback/comments on this feature or preference for {{HISTORY}} command naming.
> Add a "history" command to cqlsh. Perhaps "show history"?
> --
>
> Key: CASSANDRA-15046
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15046
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Interpreter
>Reporter: Wes Peters
>Assignee: Yundi Chen
>Priority: Low
> Labels: ghc-lhf, lhf
> Fix For: 4.x
>
>
> I was trying to capture some create key space and create table commands from
> a running cqlsh, and found there was no equivalent to the '\s' history
> command in Postgres' psql shell. It's a great tool for figuring out what you
> were doing yesterday.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15046) Add a "history" command to cqlsh. Perhaps "show history"?
[ https://issues.apache.org/jira/browse/CASSANDRA-15046?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yundi Chen updated CASSANDRA-15046: --- Test and Documentation Plan: Patch PR: [https://github.com/apache/cassandra/pull/1866/files] Documentation: Will add documentation in doc/modules/cassandra/pages/tools/cqlsh.adoc and CHANGES.md describing the HISTORY command, following the documentation style of the other cqlsh commands. The current patch implements the feature in its minimally viable form. Here's some of my ideas for improvement to current patch: # allow an input argument to control how many commands will be listed. # showing the timestamp of when each command is executed. # showing whether each command is valid/successfully executed, OR, showing only the successfully executed commands. Thoughts? was: Patch PR: [https://github.com/apache/cassandra/pull/1866/files] Documentation: Will add documentation in doc/modules/cassandra/pages/tools/cqlsh.adoc and CHANGES.md describing the HISTORY command, following the documentation style of the other cqlsh commands. > Add a "history" command to cqlsh. Perhaps "show history"? > -- > > Key: CASSANDRA-15046 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15046 > Project: Cassandra > Issue Type: Improvement > Components: CQL/Interpreter >Reporter: Wes Peters >Assignee: Yundi Chen >Priority: Low > Labels: ghc-lhf, lhf > Fix For: 4.x > > > I was trying to capture some create key space and create table commands from > a running cqlsh, and found there was no equivalent to the '\s' history > command in Postgres' psql shell. It's a great tool for figuring out what you > were doing yesterday. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15046) Add a "history" command to cqlsh. Perhaps "show history"?
[ https://issues.apache.org/jira/browse/CASSANDRA-15046?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17606401#comment-17606401 ] Yundi Chen commented on CASSANDRA-15046: The current patch implements the feature in its minimally viable form. Here's some of my ideas for improvement to current patch: # allow an input argument to control how many commands will be listed. # showing the timestamp of when each command is executed. # showing whether each command is valid/successfully executed, OR, showing only the successfully executed commands. Thoughts? > Add a "history" command to cqlsh. Perhaps "show history"? > -- > > Key: CASSANDRA-15046 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15046 > Project: Cassandra > Issue Type: Improvement > Components: CQL/Interpreter >Reporter: Wes Peters >Assignee: Yundi Chen >Priority: Low > Labels: ghc-lhf, lhf > Fix For: 4.x > > > I was trying to capture some create key space and create table commands from > a running cqlsh, and found there was no equivalent to the '\s' history > command in Postgres' psql shell. It's a great tool for figuring out what you > were doing yesterday. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15046) Add a "history" command to cqlsh. Perhaps "show history"?
[ https://issues.apache.org/jira/browse/CASSANDRA-15046?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yundi Chen updated CASSANDRA-15046: --- Mentor: Paulo Motta Test and Documentation Plan: Patch PR: [https://github.com/apache/cassandra/pull/1866/files] Documentation: Will add documentation in doc/modules/cassandra/pages/tools/cqlsh.adoc and CHANGES.md describing the HISTORY command, following the documentation style of the other cqlsh commands. Status: Patch Available (was: In Progress) > Add a "history" command to cqlsh. Perhaps "show history"? > -- > > Key: CASSANDRA-15046 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15046 > Project: Cassandra > Issue Type: Improvement > Components: CQL/Interpreter >Reporter: Wes Peters >Assignee: Yundi Chen >Priority: Low > Labels: ghc-lhf, lhf > Fix For: 4.x > > > I was trying to capture some create key space and create table commands from > a running cqlsh, and found there was no equivalent to the '\s' history > command in Postgres' psql shell. It's a great tool for figuring out what you > were doing yesterday. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17885) Add solution for CASSANDRA-17581 to older branches for tests
[ https://issues.apache.org/jira/browse/CASSANDRA-17885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17606374#comment-17606374 ] Ekaterina Dimitrova commented on CASSANDRA-17885: - No worries, I was sure it was something small. Thanks for the fix! I was waiting for all runs to finish so I can verify there is nothing else missed but it seems the turtle is still crawling... Will check back again tomorrow. > Add solution for CASSANDRA-17581 to older branches for tests > > > Key: CASSANDRA-17885 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17885 > Project: Cassandra > Issue Type: Bug > Components: Tool/nodetool >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x, 4.x > > > Some of our tests use old branches for the purposes of testing upgrades and > behavior in mixed versions, but those lacking CASSANDRA-17581 will fail on > nodetool with a modern JDK. We can port this fix to those branches and > adjust the tests to use the newest version of them to solve this going > forward. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17904) Consider to not warn about deprecated properties in logs when the value is not deprecated
[
https://issues.apache.org/jira/browse/CASSANDRA-17904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17606373#comment-17606373
]
Ekaterina Dimitrova commented on CASSANDRA-17904:
-
Thanks [~smiklosovic], those three are special case where only the value format
was changed and their names were kept (the only 3 which had proper names and no
unit as part of the name... ), that's why your valid observation - they emit
deprecation warning even with the value being in the new format. You made me
wonder whether it was worth it to special case them at all, I will take a look
tomorrow.
> Consider to not warn about deprecated properties in logs when the value is
> not deprecated
> -
>
> Key: CASSANDRA-17904
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17904
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Stefan Miklosovic
>Priority: Normal
>
> When there is an initialisation of database descriptor for tools, for example
> via "Util.initDatabaseDescriptor()", it will eventually buble up to
> "YamlConfigurationLoader.check" where this is logged:
> {code}
> if (!deprecationWarnings.isEmpty())
> logger.warn("{} parameters have been deprecated. They have new names and/or
> value format; For more information, please refer to NEWS.txt",
> deprecationWarnings);
> {code}
> For example, I saw this log:
> {code}
> WARN 09:07:42,486 [key_cache_save_period, counter_cache_save_period,
> row_cache_save_period] parameters have been deprecated. They have new names
> and/or value format; For more information, please refer to NEWS.txt
> {code}
> The "problems" I see are two:
> 1) it pollutes the console for tool commands, when a tool needs to initialise
> DD, at the very beginning of the output.
> 2) When you look closely, for example at key_cache_save_period, by default,
> in cassandra.yaml, it has value "4h". My question is: why is it necessary to
> mark that as deprecated when the value is already in new format? In other
> words, I would log that warning only in case that the expected value of a
> property is not in the new format. But when it already is, why do we need to
> inform a user about that?
> I think it would require to take some extra care for cases like these in
> YamlConfigurationLoader.getProperty to not add deprecated properties if their
> value is already new.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17221) Add Math functions
[
https://issues.apache.org/jira/browse/CASSANDRA-17221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17606369#comment-17606369
]
Simon Chess commented on CASSANDRA-17221:
-
Hi [~blerer], [~e.dimitrova],
It's been a month since I've heard from you, and four since I've touched the
code; this is my first checkin to Cassandra, is this normal? What can I do to
speed things up?
> Add Math functions
> ---
>
> Key: CASSANDRA-17221
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17221
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Syntax
>Reporter: Benjamin Lerer
>Assignee: Simon Chess
>Priority: Normal
> Labels: AdventCalendar2021, lhf
> Fix For: 4.x
>
>
> We should add native Maths functions for the most common operations:
> * {{abs\(x)}} returns the absolute value of the x
> * {{exp\(x)}} returns the value of e (the base of natural logarithms) raised
> to the power of x
> * {{log\(x)}} returns the natural logarithm (base e) of x
> * {{log10\(x)}} returns the base-10 logarithm of x
> * {{round\(x)}} returns the closest integer to x
> +Additional information for newcomers:+
> The new functions should be put in a new class {{MathFcts}} similar to
> {{TimeFcts}}.
> The {{MathsFcts.all()}} method should be called in
> {{SystemKeyspace.functions}}
> The unit tests for the functions should be put in a {{MathFctsTest}} similar
> to {{TimeFctsTest}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16860) Add --older-than option to nodetool clearsnapshot
[
https://issues.apache.org/jira/browse/CASSANDRA-16860?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paulo Motta updated CASSANDRA-16860:
Status: Open (was: Patch Available)
> Add --older-than option to nodetool clearsnapshot
> -
>
> Key: CASSANDRA-16860
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16860
> Project: Cassandra
> Issue Type: New Feature
> Components: Local/Snapshots, Tool/nodetool
>Reporter: Jack Casey
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> h1. Summary
> Opening this issue in reference to [this WIP
> PR|https://github.com/apache/cassandra/pull/1148]:
> This functionality allows users of Cassandra to remove snapshots ad-hoc,
> based on a TTL. This is to address the problem of snapshots accumulating. For
> example, an organization I work for aims to keep snapshots for 30 days,
> however we don't have any way to easily clean them after those 30 days are up.
> This is similar to the goals set in:
> https://issues.apache.org/jira/browse/CASSANDRA-16451 however would be
> available for Cassandra 3.x.
> h1. Functionality
> This adds a new command to NodeTool, called {{expiresnapshot}} with the
> following options:
> NAME
> nodetool expiresnapshots - Removes snapshots that are older than a TTL
> in days
> SYNOPSIS
> nodetool [(-h | --host )] [(-p | --port )]
> [(-pw | --password )]
> [(-pwf | --password-file )]
> [(-u | --username )] expiresnapshots [--dry-run]
> (-t | --ttl )
> OPTIONS
> --dry-run
> Run without actually clearing snapshots
> -h , --host
> Node hostname or ip address
> -p , --port
> Remote jmx agent port number
> -pw , --password
> Remote jmx agent password
> -pwf , --password-file
> Path to the JMX password file
> -t , --ttl
> TTL (in days) to expire snapshots
> -u , --username
> Remote jmx agent username
> The snapshot date is taken by converting the default snapshot name timestamps
> (epoch time in miliseconds). For this reason, snapshot names that don't
> contain a timestamp in this format will not be cleared.
> h1. Example Use
> This Cassandra environment has a number of snapshots, a few are recent, and a
> few outdated:
> root@cassandra001:/cassandra# nodetool listsnapshots
> Snapshot Details:
> Snapshot name Keyspace name Column family name True size Size on disk
> 1529173922063 users_keyspace users 362.03 KiB 362.89 KiB
> 1629173909461 users_keyspace users 362.03 KiB 362.89 KiB
> 1629173922063 users_keyspace users 362.03 KiB 362.89 KiB
> 1599173922063 users_keyspace users 362.03 KiB 362.89 KiB
> 1629173916816 users_keyspace users 362.03 KiB 362.89 KiB
> Total TrueDiskSpaceUsed: 1.77 MiB
> To validate the removal runs as expected, we can use the `--dry-run` option:
> root@cassandra001:/cassandra# nodetool expiresnapshots --ttl 30 --dry-run
> Starting simulated cleanup of snapshots older than 30 days
> Clearing (dry run): 1529173922063
> Clearing (dry run): 1599173922063
> Cleared (dry run): 2 snapshots
> Now that we are confident the correct snapshots will be removed, we can omit
> the {{--dry-run}} flag:
> root@cassandra001:/cassandra# nodetool expiresnapshots --ttl 30
> Starting cleanup of snapshots older than 30 days
> Clearing: 1529173922063
> Clearing: 1599173922063
> Cleared: 2 snapshots
> To confirm our changes are successful, we list the snapshots that still
> remain:
> root@cassandra001:/cassandra# nodetool listsnapshots
> Snapshot Details:
> Snapshot name Keyspace name Column family name True size Size on disk
> 1629173909461 users_keyspace users 362.03 KiB 362.89 KiB
> 1629173922063 users_keyspace users 362.03 KiB 362.89 KiB
> 1629173916816 users_keyspace users 362.03 KiB 362.89 KiB
> Total TrueDiskSpaceUsed: 1.06 MiB
> h1. Next Steps
> To be completed:
> - Tests
> - Documentation updates
> I am a new to this repository, and am fuzzy on a few details even after
> reading the contribution guide Any advice on the following would be greatly
> appreciated!
> - What branch would this type of change be merged into? Currently, I'm
> targeting {{apache:trunk}} by default
> - Is there a test strategy/pattern for this type of change? I was not able
> to find any existing tests for similar {{nodetool}} commands
> Thanks!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16860) Add --older-than option to nodetool clearsnapshot
[
https://issues.apache.org/jira/browse/CASSANDRA-16860?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paulo Motta updated CASSANDRA-16860:
Reviewers: Paulo Motta
> Add --older-than option to nodetool clearsnapshot
> -
>
> Key: CASSANDRA-16860
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16860
> Project: Cassandra
> Issue Type: New Feature
> Components: Local/Snapshots, Tool/nodetool
>Reporter: Jack Casey
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> h1. Summary
> Opening this issue in reference to [this WIP
> PR|https://github.com/apache/cassandra/pull/1148]:
> This functionality allows users of Cassandra to remove snapshots ad-hoc,
> based on a TTL. This is to address the problem of snapshots accumulating. For
> example, an organization I work for aims to keep snapshots for 30 days,
> however we don't have any way to easily clean them after those 30 days are up.
> This is similar to the goals set in:
> https://issues.apache.org/jira/browse/CASSANDRA-16451 however would be
> available for Cassandra 3.x.
> h1. Functionality
> This adds a new command to NodeTool, called {{expiresnapshot}} with the
> following options:
> NAME
> nodetool expiresnapshots - Removes snapshots that are older than a TTL
> in days
> SYNOPSIS
> nodetool [(-h | --host )] [(-p | --port )]
> [(-pw | --password )]
> [(-pwf | --password-file )]
> [(-u | --username )] expiresnapshots [--dry-run]
> (-t | --ttl )
> OPTIONS
> --dry-run
> Run without actually clearing snapshots
> -h , --host
> Node hostname or ip address
> -p , --port
> Remote jmx agent port number
> -pw , --password
> Remote jmx agent password
> -pwf , --password-file
> Path to the JMX password file
> -t , --ttl
> TTL (in days) to expire snapshots
> -u , --username
> Remote jmx agent username
> The snapshot date is taken by converting the default snapshot name timestamps
> (epoch time in miliseconds). For this reason, snapshot names that don't
> contain a timestamp in this format will not be cleared.
> h1. Example Use
> This Cassandra environment has a number of snapshots, a few are recent, and a
> few outdated:
> root@cassandra001:/cassandra# nodetool listsnapshots
> Snapshot Details:
> Snapshot name Keyspace name Column family name True size Size on disk
> 1529173922063 users_keyspace users 362.03 KiB 362.89 KiB
> 1629173909461 users_keyspace users 362.03 KiB 362.89 KiB
> 1629173922063 users_keyspace users 362.03 KiB 362.89 KiB
> 1599173922063 users_keyspace users 362.03 KiB 362.89 KiB
> 1629173916816 users_keyspace users 362.03 KiB 362.89 KiB
> Total TrueDiskSpaceUsed: 1.77 MiB
> To validate the removal runs as expected, we can use the `--dry-run` option:
> root@cassandra001:/cassandra# nodetool expiresnapshots --ttl 30 --dry-run
> Starting simulated cleanup of snapshots older than 30 days
> Clearing (dry run): 1529173922063
> Clearing (dry run): 1599173922063
> Cleared (dry run): 2 snapshots
> Now that we are confident the correct snapshots will be removed, we can omit
> the {{--dry-run}} flag:
> root@cassandra001:/cassandra# nodetool expiresnapshots --ttl 30
> Starting cleanup of snapshots older than 30 days
> Clearing: 1529173922063
> Clearing: 1599173922063
> Cleared: 2 snapshots
> To confirm our changes are successful, we list the snapshots that still
> remain:
> root@cassandra001:/cassandra# nodetool listsnapshots
> Snapshot Details:
> Snapshot name Keyspace name Column family name True size Size on disk
> 1629173909461 users_keyspace users 362.03 KiB 362.89 KiB
> 1629173922063 users_keyspace users 362.03 KiB 362.89 KiB
> 1629173916816 users_keyspace users 362.03 KiB 362.89 KiB
> Total TrueDiskSpaceUsed: 1.06 MiB
> h1. Next Steps
> To be completed:
> - Tests
> - Documentation updates
> I am a new to this repository, and am fuzzy on a few details even after
> reading the contribution guide Any advice on the following would be greatly
> appreciated!
> - What branch would this type of change be merged into? Currently, I'm
> targeting {{apache:trunk}} by default
> - Is there a test strategy/pattern for this type of change? I was not able
> to find any existing tests for similar {{nodetool}} commands
> Thanks!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16860) Add --older-than option to nodetool clearsnapshot
[
https://issues.apache.org/jira/browse/CASSANDRA-16860?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17606291#comment-17606291
]
Paulo Motta commented on CASSANDRA-16860:
-
Sorry missed your earlier ping. Added a few comments to the PR.
> Add --older-than option to nodetool clearsnapshot
> -
>
> Key: CASSANDRA-16860
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16860
> Project: Cassandra
> Issue Type: New Feature
> Components: Local/Snapshots, Tool/nodetool
>Reporter: Jack Casey
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> h1. Summary
> Opening this issue in reference to [this WIP
> PR|https://github.com/apache/cassandra/pull/1148]:
> This functionality allows users of Cassandra to remove snapshots ad-hoc,
> based on a TTL. This is to address the problem of snapshots accumulating. For
> example, an organization I work for aims to keep snapshots for 30 days,
> however we don't have any way to easily clean them after those 30 days are up.
> This is similar to the goals set in:
> https://issues.apache.org/jira/browse/CASSANDRA-16451 however would be
> available for Cassandra 3.x.
> h1. Functionality
> This adds a new command to NodeTool, called {{expiresnapshot}} with the
> following options:
> NAME
> nodetool expiresnapshots - Removes snapshots that are older than a TTL
> in days
> SYNOPSIS
> nodetool [(-h | --host )] [(-p | --port )]
> [(-pw | --password )]
> [(-pwf | --password-file )]
> [(-u | --username )] expiresnapshots [--dry-run]
> (-t | --ttl )
> OPTIONS
> --dry-run
> Run without actually clearing snapshots
> -h , --host
> Node hostname or ip address
> -p , --port
> Remote jmx agent port number
> -pw , --password
> Remote jmx agent password
> -pwf , --password-file
> Path to the JMX password file
> -t , --ttl
> TTL (in days) to expire snapshots
> -u , --username
> Remote jmx agent username
> The snapshot date is taken by converting the default snapshot name timestamps
> (epoch time in miliseconds). For this reason, snapshot names that don't
> contain a timestamp in this format will not be cleared.
> h1. Example Use
> This Cassandra environment has a number of snapshots, a few are recent, and a
> few outdated:
> root@cassandra001:/cassandra# nodetool listsnapshots
> Snapshot Details:
> Snapshot name Keyspace name Column family name True size Size on disk
> 1529173922063 users_keyspace users 362.03 KiB 362.89 KiB
> 1629173909461 users_keyspace users 362.03 KiB 362.89 KiB
> 1629173922063 users_keyspace users 362.03 KiB 362.89 KiB
> 1599173922063 users_keyspace users 362.03 KiB 362.89 KiB
> 1629173916816 users_keyspace users 362.03 KiB 362.89 KiB
> Total TrueDiskSpaceUsed: 1.77 MiB
> To validate the removal runs as expected, we can use the `--dry-run` option:
> root@cassandra001:/cassandra# nodetool expiresnapshots --ttl 30 --dry-run
> Starting simulated cleanup of snapshots older than 30 days
> Clearing (dry run): 1529173922063
> Clearing (dry run): 1599173922063
> Cleared (dry run): 2 snapshots
> Now that we are confident the correct snapshots will be removed, we can omit
> the {{--dry-run}} flag:
> root@cassandra001:/cassandra# nodetool expiresnapshots --ttl 30
> Starting cleanup of snapshots older than 30 days
> Clearing: 1529173922063
> Clearing: 1599173922063
> Cleared: 2 snapshots
> To confirm our changes are successful, we list the snapshots that still
> remain:
> root@cassandra001:/cassandra# nodetool listsnapshots
> Snapshot Details:
> Snapshot name Keyspace name Column family name True size Size on disk
> 1629173909461 users_keyspace users 362.03 KiB 362.89 KiB
> 1629173922063 users_keyspace users 362.03 KiB 362.89 KiB
> 1629173916816 users_keyspace users 362.03 KiB 362.89 KiB
> Total TrueDiskSpaceUsed: 1.06 MiB
> h1. Next Steps
> To be completed:
> - Tests
> - Documentation updates
> I am a new to this repository, and am fuzzy on a few details even after
> reading the contribution guide Any advice on the following would be greatly
> appreciated!
> - What branch would this type of change be merged into? Currently, I'm
> targeting {{apache:trunk}} by default
> - Is there a test strategy/pattern for this type of change? I was not able
> to find any existing tests for similar {{nodetool}} commands
> Thanks!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17904) Consider to not warn about deprecated properties in logs when the value is not deprecated
[
https://issues.apache.org/jira/browse/CASSANDRA-17904?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-17904:
--
Description:
When there is an initialisation of database descriptor for tools, for example
via "Util.initDatabaseDescriptor()", it will eventually buble up to
"YamlConfigurationLoader.check" where this is logged:
{code}
if (!deprecationWarnings.isEmpty())
logger.warn("{} parameters have been deprecated. They have new names and/or
value format; For more information, please refer to NEWS.txt",
deprecationWarnings);
{code}
For example, I saw this log:
{code}
WARN 09:07:42,486 [key_cache_save_period, counter_cache_save_period,
row_cache_save_period] parameters have been deprecated. They have new names
and/or value format; For more information, please refer to NEWS.txt
{code}
The "problems" I see are two:
1) it pollutes the console for tool commands, when a tool needs to initialise
DD, at the very beginning of the output.
2) When you look closely, for example at key_cache_save_period, by default, in
cassandra.yaml, it has value "4h". My question is: why is it necessary to mark
that as deprecated when the value is already in new format? In other words, I
would log that warning only in case that the expected value of a property is
not in the new format. But when it already is, why do we need to inform a user
about that?
I think it would require to take some extra care for cases like these in
YamlConfigurationLoader.getProperty to not add deprecated properties if their
value is already new.
was:
When there is an initialisation of database descriptor for tools, for example
via "Util.initDatabaseDescriptor()", it will eventually buble up to
"YamlConfigurationLoader.check" where this is logged:
{code}
if (!deprecationWarnings.isEmpty())
logger.warn("{} parameters have been deprecated. They have new names and/or
value format; For more information, please refer to NEWS.txt",
deprecationWarnings);
{code}
For example, I saw this log:
{code}
WARN 09:07:42,486 [key_cache_save_period, counter_cache_save_period,
row_cache_save_period] parameters have been deprecated. They have new names
and/or value format; For more information, please refer to NEWS.txt
{code}
The "problems" I see are two:
1) it pollutes the console for tool commands, when a tool needs to initialise
DD, at the very beginning of the output.
2) When you look closely, for example at key_cache_save_period, by defaul, in
cassandra.yaml, it has value "4h". My question is: why is it necessary to mark
that as deprecated when the value is already in new format? In other words, I
would log that warning only in case that the expected value of a property is
not in the new format. But when it already is, why do we need to inform a user
about that?
I think it would require to take some extra care for cases like these in
YamlConfigurationLoader.getProperty to not add deprecated properties if their
value is already new.
> Consider to not warn about deprecated properties in logs when the value is
> not deprecated
> -
>
> Key: CASSANDRA-17904
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17904
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Stefan Miklosovic
>Priority: Normal
>
> When there is an initialisation of database descriptor for tools, for example
> via "Util.initDatabaseDescriptor()", it will eventually buble up to
> "YamlConfigurationLoader.check" where this is logged:
> {code}
> if (!deprecationWarnings.isEmpty())
> logger.warn("{} parameters have been deprecated. They have new names and/or
> value format; For more information, please refer to NEWS.txt",
> deprecationWarnings);
> {code}
> For example, I saw this log:
> {code}
> WARN 09:07:42,486 [key_cache_save_period, counter_cache_save_period,
> row_cache_save_period] parameters have been deprecated. They have new names
> and/or value format; For more information, please refer to NEWS.txt
> {code}
> The "problems" I see are two:
> 1) it pollutes the console for tool commands, when a tool needs to initialise
> DD, at the very beginning of the output.
> 2) When you look closely, for example at key_cache_save_period, by default,
> in cassandra.yaml, it has value "4h". My question is: why is it necessary to
> mark that as deprecated when the value is already in new format? In other
> words, I would log that warning only in case that the expected value of a
> property is not in the new format. But when it already is, why do we need to
> inform a user about that?
> I think it would require to take some extra care for cases like these in
> YamlConfigurationLoader.getProperty to not add deprecated properties if their
> value is already new.
>
--
[jira] [Commented] (CASSANDRA-17904) Consider to not warn about deprecated properties in logs when the value is not deprecated
[
https://issues.apache.org/jira/browse/CASSANDRA-17904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17606250#comment-17606250
]
Stefan Miklosovic commented on CASSANDRA-17904:
---
Kindly pinging [~e.dimitrova] to raise awareness.
> Consider to not warn about deprecated properties in logs when the value is
> not deprecated
> -
>
> Key: CASSANDRA-17904
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17904
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Stefan Miklosovic
>Priority: Normal
>
> When there is an initialisation of database descriptor for tools, for example
> via "Util.initDatabaseDescriptor()", it will eventually buble up to
> "YamlConfigurationLoader.check" where this is logged:
> {code}
> if (!deprecationWarnings.isEmpty())
> logger.warn("{} parameters have been deprecated. They have new names and/or
> value format; For more information, please refer to NEWS.txt",
> deprecationWarnings);
> {code}
> For example, I saw this log:
> {code}
> WARN 09:07:42,486 [key_cache_save_period, counter_cache_save_period,
> row_cache_save_period] parameters have been deprecated. They have new names
> and/or value format; For more information, please refer to NEWS.txt
> {code}
> The "problems" I see are two:
> 1) it pollutes the console for tool commands, when a tool needs to initialise
> DD, at the very beginning of the output.
> 2) When you look closely, for example at key_cache_save_period, by defaul, in
> cassandra.yaml, it has value "4h". My question is: why is it necessary to
> mark that as deprecated when the value is already in new format? In other
> words, I would log that warning only in case that the expected value of a
> property is not in the new format. But when it already is, why do we need to
> inform a user about that?
> I think it would require to take some extra care for cases like these in
> YamlConfigurationLoader.getProperty to not add deprecated properties if their
> value is already new.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-17904) Consider to not warn about deprecated properties in logs when the value is not deprecated
Stefan Miklosovic created CASSANDRA-17904:
-
Summary: Consider to not warn about deprecated properties in logs
when the value is not deprecated
Key: CASSANDRA-17904
URL: https://issues.apache.org/jira/browse/CASSANDRA-17904
Project: Cassandra
Issue Type: Improvement
Reporter: Stefan Miklosovic
When there is an initialisation of database descriptor for tools, for example
via "Util.initDatabaseDescriptor()", it will eventually buble up to
"YamlConfigurationLoader.check" where this is logged:
{code}
if (!deprecationWarnings.isEmpty())
logger.warn("{} parameters have been deprecated. They have new names and/or
value format; For more information, please refer to NEWS.txt",
deprecationWarnings);
{code}
For example, I saw this log:
{code}
WARN 09:07:42,486 [key_cache_save_period, counter_cache_save_period,
row_cache_save_period] parameters have been deprecated. They have new names
and/or value format; For more information, please refer to NEWS.txt
{code}
The "problems" I see are two:
1) it pollutes the console for tool commands, when a tool needs to initialise
DD, at the very beginning of the output.
2) When you look closely, for example at key_cache_save_period, by defaul, in
cassandra.yaml, it has value "4h". My question is: why is it necessary to mark
that as deprecated when the value is already in new format? In other words, I
would log that warning only in case that the expected value of a property is
not in the new format. But when it already is, why do we need to inform a user
about that?
I think it would require to take some extra care for cases like these in
YamlConfigurationLoader.getProperty to not add deprecated properties if their
value is already new.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16860) Add --older-than option to nodetool clearsnapshot
[
https://issues.apache.org/jira/browse/CASSANDRA-16860?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17606245#comment-17606245
]
Stefan Miklosovic commented on CASSANDRA-16860:
---
Hi [~e.dimitrova] , would you mind to take a look? I see you are among watchers.
> Add --older-than option to nodetool clearsnapshot
> -
>
> Key: CASSANDRA-16860
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16860
> Project: Cassandra
> Issue Type: New Feature
> Components: Local/Snapshots, Tool/nodetool
>Reporter: Jack Casey
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.x
>
>
> h1. Summary
> Opening this issue in reference to [this WIP
> PR|https://github.com/apache/cassandra/pull/1148]:
> This functionality allows users of Cassandra to remove snapshots ad-hoc,
> based on a TTL. This is to address the problem of snapshots accumulating. For
> example, an organization I work for aims to keep snapshots for 30 days,
> however we don't have any way to easily clean them after those 30 days are up.
> This is similar to the goals set in:
> https://issues.apache.org/jira/browse/CASSANDRA-16451 however would be
> available for Cassandra 3.x.
> h1. Functionality
> This adds a new command to NodeTool, called {{expiresnapshot}} with the
> following options:
> NAME
> nodetool expiresnapshots - Removes snapshots that are older than a TTL
> in days
> SYNOPSIS
> nodetool [(-h | --host )] [(-p | --port )]
> [(-pw | --password )]
> [(-pwf | --password-file )]
> [(-u | --username )] expiresnapshots [--dry-run]
> (-t | --ttl )
> OPTIONS
> --dry-run
> Run without actually clearing snapshots
> -h , --host
> Node hostname or ip address
> -p , --port
> Remote jmx agent port number
> -pw , --password
> Remote jmx agent password
> -pwf , --password-file
> Path to the JMX password file
> -t , --ttl
> TTL (in days) to expire snapshots
> -u , --username
> Remote jmx agent username
> The snapshot date is taken by converting the default snapshot name timestamps
> (epoch time in miliseconds). For this reason, snapshot names that don't
> contain a timestamp in this format will not be cleared.
> h1. Example Use
> This Cassandra environment has a number of snapshots, a few are recent, and a
> few outdated:
> root@cassandra001:/cassandra# nodetool listsnapshots
> Snapshot Details:
> Snapshot name Keyspace name Column family name True size Size on disk
> 1529173922063 users_keyspace users 362.03 KiB 362.89 KiB
> 1629173909461 users_keyspace users 362.03 KiB 362.89 KiB
> 1629173922063 users_keyspace users 362.03 KiB 362.89 KiB
> 1599173922063 users_keyspace users 362.03 KiB 362.89 KiB
> 1629173916816 users_keyspace users 362.03 KiB 362.89 KiB
> Total TrueDiskSpaceUsed: 1.77 MiB
> To validate the removal runs as expected, we can use the `--dry-run` option:
> root@cassandra001:/cassandra# nodetool expiresnapshots --ttl 30 --dry-run
> Starting simulated cleanup of snapshots older than 30 days
> Clearing (dry run): 1529173922063
> Clearing (dry run): 1599173922063
> Cleared (dry run): 2 snapshots
> Now that we are confident the correct snapshots will be removed, we can omit
> the {{--dry-run}} flag:
> root@cassandra001:/cassandra# nodetool expiresnapshots --ttl 30
> Starting cleanup of snapshots older than 30 days
> Clearing: 1529173922063
> Clearing: 1599173922063
> Cleared: 2 snapshots
> To confirm our changes are successful, we list the snapshots that still
> remain:
> root@cassandra001:/cassandra# nodetool listsnapshots
> Snapshot Details:
> Snapshot name Keyspace name Column family name True size Size on disk
> 1629173909461 users_keyspace users 362.03 KiB 362.89 KiB
> 1629173922063 users_keyspace users 362.03 KiB 362.89 KiB
> 1629173916816 users_keyspace users 362.03 KiB 362.89 KiB
> Total TrueDiskSpaceUsed: 1.06 MiB
> h1. Next Steps
> To be completed:
> - Tests
> - Documentation updates
> I am a new to this repository, and am fuzzy on a few details even after
> reading the contribution guide Any advice on the following would be greatly
> appreciated!
> - What branch would this type of change be merged into? Currently, I'm
> targeting {{apache:trunk}} by default
> - Is there a test strategy/pattern for this type of change? I was not able
> to find any existing tests for similar {{nodetool}} commands
> Thanks!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16860) Add --older-than option to nodetool clearsnapshot
[
https://issues.apache.org/jira/browse/CASSANDRA-16860?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-16860:
--
Reviewers: (was: Paulo Motta)
> Add --older-than option to nodetool clearsnapshot
> -
>
> Key: CASSANDRA-16860
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16860
> Project: Cassandra
> Issue Type: New Feature
> Components: Local/Snapshots, Tool/nodetool
>Reporter: Jack Casey
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.x
>
>
> h1. Summary
> Opening this issue in reference to [this WIP
> PR|https://github.com/apache/cassandra/pull/1148]:
> This functionality allows users of Cassandra to remove snapshots ad-hoc,
> based on a TTL. This is to address the problem of snapshots accumulating. For
> example, an organization I work for aims to keep snapshots for 30 days,
> however we don't have any way to easily clean them after those 30 days are up.
> This is similar to the goals set in:
> https://issues.apache.org/jira/browse/CASSANDRA-16451 however would be
> available for Cassandra 3.x.
> h1. Functionality
> This adds a new command to NodeTool, called {{expiresnapshot}} with the
> following options:
> NAME
> nodetool expiresnapshots - Removes snapshots that are older than a TTL
> in days
> SYNOPSIS
> nodetool [(-h | --host )] [(-p | --port )]
> [(-pw | --password )]
> [(-pwf | --password-file )]
> [(-u | --username )] expiresnapshots [--dry-run]
> (-t | --ttl )
> OPTIONS
> --dry-run
> Run without actually clearing snapshots
> -h , --host
> Node hostname or ip address
> -p , --port
> Remote jmx agent port number
> -pw , --password
> Remote jmx agent password
> -pwf , --password-file
> Path to the JMX password file
> -t , --ttl
> TTL (in days) to expire snapshots
> -u , --username
> Remote jmx agent username
> The snapshot date is taken by converting the default snapshot name timestamps
> (epoch time in miliseconds). For this reason, snapshot names that don't
> contain a timestamp in this format will not be cleared.
> h1. Example Use
> This Cassandra environment has a number of snapshots, a few are recent, and a
> few outdated:
> root@cassandra001:/cassandra# nodetool listsnapshots
> Snapshot Details:
> Snapshot name Keyspace name Column family name True size Size on disk
> 1529173922063 users_keyspace users 362.03 KiB 362.89 KiB
> 1629173909461 users_keyspace users 362.03 KiB 362.89 KiB
> 1629173922063 users_keyspace users 362.03 KiB 362.89 KiB
> 1599173922063 users_keyspace users 362.03 KiB 362.89 KiB
> 1629173916816 users_keyspace users 362.03 KiB 362.89 KiB
> Total TrueDiskSpaceUsed: 1.77 MiB
> To validate the removal runs as expected, we can use the `--dry-run` option:
> root@cassandra001:/cassandra# nodetool expiresnapshots --ttl 30 --dry-run
> Starting simulated cleanup of snapshots older than 30 days
> Clearing (dry run): 1529173922063
> Clearing (dry run): 1599173922063
> Cleared (dry run): 2 snapshots
> Now that we are confident the correct snapshots will be removed, we can omit
> the {{--dry-run}} flag:
> root@cassandra001:/cassandra# nodetool expiresnapshots --ttl 30
> Starting cleanup of snapshots older than 30 days
> Clearing: 1529173922063
> Clearing: 1599173922063
> Cleared: 2 snapshots
> To confirm our changes are successful, we list the snapshots that still
> remain:
> root@cassandra001:/cassandra# nodetool listsnapshots
> Snapshot Details:
> Snapshot name Keyspace name Column family name True size Size on disk
> 1629173909461 users_keyspace users 362.03 KiB 362.89 KiB
> 1629173922063 users_keyspace users 362.03 KiB 362.89 KiB
> 1629173916816 users_keyspace users 362.03 KiB 362.89 KiB
> Total TrueDiskSpaceUsed: 1.06 MiB
> h1. Next Steps
> To be completed:
> - Tests
> - Documentation updates
> I am a new to this repository, and am fuzzy on a few details even after
> reading the contribution guide Any advice on the following would be greatly
> appreciated!
> - What branch would this type of change be merged into? Currently, I'm
> targeting {{apache:trunk}} by default
> - Is there a test strategy/pattern for this type of change? I was not able
> to find any existing tests for similar {{nodetool}} commands
> Thanks!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
