Re: [DISCUSS] CASSANDRA-19104: Standardize tablestats formatting and data units

[Miklosovic, Stefan via dev]

Hi Claude,

while technically possible, I do not see a lot of people would use this. I am 
for straightforward -H option instead of introducing -Hn which seems to bring 
almost no value and brings discrepancy into the nodetool flags. I think there 
are other -H outputs for other commands, are not there? Should not we then also 
take a look if -Hn is not applicable for them as well? Anyway ... this seems to 
be just a lot of work with almost no benefit.

Regards


From: Claude Warren, Jr via dev 
Sent: Tuesday, December 5, 2023 8:46
To: dev@cassandra.apache.org
Cc: Claude Warren, Jr
Subject: Re: [DISCUSS] CASSANDRA-19104: Standardize tablestats formatting and 
data units

EXTERNAL EMAIL - USE CAUTION when clicking links or attachments



Why not change the option so that -H will operate as it does now while -Hn 
(where n is a digit) will limit the number of decimal places to n.

On Mon, Dec 4, 2023 at 5:11 PM Brad 
mailto:bscho...@gmail.com>> wrote:
Thanks, Jacek.  Using three significant digits for disk space is a good 
suggestion.

On Mon, Dec 4, 2023 at 9:58 AM Jacek Lewandowski 
mailto:lewandowski.ja...@gmail.com>> wrote:
This looks great,

I'd consider limiting the number of significant digits to 3 in the human 
readable format. In the above example it would translate to:

Space used (live): 1.46 TiB
Space used (total): 1.46 TiB

Bytes repaired: 0.00 KiB
Bytes unrepaired: 4.31 TiB
Bytes pending repair: 0.000 KiB

I just think with human readable format we just expect to have a grasp view of 
the stats and 4th significant digit has very little meaning in that case.


thanks,
Jacek

Re: [VOTE] Release Apache Cassandra 5.0-beta1 (take2)

[Maxim Muzafarov]

+1 (nb)

run locally, executed some queries over vts

On Mon, 4 Dec 2023 at 15:15, Brandon Williams  wrote:
>
> +1
>
> Kind Regards,
> Brandon
>
> On Fri, Dec 1, 2023 at 7:32 AM Mick Semb Wever  wrote:
> >
> >
> > Proposing the test build of Cassandra 5.0-beta1 for release.
> >
> > sha1: 87fd1fa88a0c859cc32d9f569ad09ad0b345e465
> > Git: https://github.com/apache/cassandra/tree/5.0-beta1-tentative
> > Maven Artifacts: 
> > https://repository.apache.org/content/repositories/orgapachecassandra-1321/org/apache/cassandra/cassandra-all/5.0-beta1/
> >
> > The Source and Build Artifacts, and the Debian and RPM packages and 
> > repositories, are available here: 
> > https://dist.apache.org/repos/dist/dev/cassandra/5.0-beta1/
> >
> > The vote will be open for 72 hours (longer if needed). Everyone who has 
> > tested the build is invited to vote. Votes by PMC members are considered 
> > binding. A vote passes if there are at least three binding +1s and no -1's.
> >
> > [1]: CHANGES.txt: 
> > https://github.com/apache/cassandra/blob/5.0-beta1-tentative/CHANGES.txt
> > [2]: NEWS.txt: 
> > https://github.com/apache/cassandra/blob/5.0-beta1-tentative/NEWS.txt

Re: [VOTE] Release Apache Cassandra 5.0-beta1 (take2)

[Benjamin Lerer]

+1

Le mar. 5 déc. 2023 à 12:23, Maxim Muzafarov  a écrit :

> +1 (nb)
>
> run locally, executed some queries over vts
>
> On Mon, 4 Dec 2023 at 15:15, Brandon Williams  wrote:
> >
> > +1
> >
> > Kind Regards,
> > Brandon
> >
> > On Fri, Dec 1, 2023 at 7:32 AM Mick Semb Wever  wrote:
> > >
> > >
> > > Proposing the test build of Cassandra 5.0-beta1 for release.
> > >
> > > sha1: 87fd1fa88a0c859cc32d9f569ad09ad0b345e465
> > > Git: https://github.com/apache/cassandra/tree/5.0-beta1-tentative
> > > Maven Artifacts:
> https://repository.apache.org/content/repositories/orgapachecassandra-1321/org/apache/cassandra/cassandra-all/5.0-beta1/
> > >
> > > The Source and Build Artifacts, and the Debian and RPM packages and
> repositories, are available here:
> https://dist.apache.org/repos/dist/dev/cassandra/5.0-beta1/
> > >
> > > The vote will be open for 72 hours (longer if needed). Everyone who
> has tested the build is invited to vote. Votes by PMC members are
> considered binding. A vote passes if there are at least three binding +1s
> and no -1's.
> > >
> > > [1]: CHANGES.txt:
> https://github.com/apache/cassandra/blob/5.0-beta1-tentative/CHANGES.txt
> > > [2]: NEWS.txt:
> https://github.com/apache/cassandra/blob/5.0-beta1-tentative/NEWS.txt
>

[RESULT][VOTE] Release Apache Cassandra 5.0-beta1 (take2)

[Mick Semb Wever]

> The vote will be open for 72 hours (longer if needed). Everyone who has
> tested the build is invited to vote. Votes by PMC members are considered
> binding. A vote passes if there are at least three binding +1s and no -1's.
>


The vote passes with five +1s (three binding).

Re: [DISCUSSION] CEP-38: CQL Management API

[Venkata Hari Krishna Nukala]

Hi Maxim,

I think this CEP is a great start to viewing Cassandra operations in a
different way! However, I have a few questions about it.

   - How are the results of the commands expressed to the CQL client? Since
   the command is being treated as CQL, I guess it will be rows, right? If
   yes, some of the nodetool commands output are a bit hierarchical in nature
   (e.g. cfstats, netstats etc...). How are these cases handled?
   - Any changes expected at client/driver side? While using JMX/nodetool,
   it is clear that the command/operations are getting executed against which
   Cassandra node. But a client can connect to multiple hosts and trigger
   queries, then how can it ensure that commands are executed against the
   desired Cassandra instance?
   - The term COMMAND is a bit abstract I feel (subjective). Some of the
   examples quoted are referring to updating settings (for example: EXECUTE
   COMMAND setconcurrentcompactors WITH concurrent_compactors=5;) and some are
   referring to operations. Updating settings and running operations are
   considerably different things. They may have to be handled in their own
   way. And I also feel the settings part is overlapping with virtual tables.
   If virtual tables support writes (at least the settings virtual table),
   then settings can be updated using the virtual table itself.
   - How are the responses of different operations expressed through the
   Command API? If the Command Registry Adapters depend upon the command
   metadata for invoking/validating the command, then I think there has to be
   a way for them to interpret the response format also, right?


Thanks!
Hari

On Wed, Nov 29, 2023 at 12:55 AM Alexander DEJANOVSKI 
wrote:

> Hi Maxim,
>
> I'm part of the K8ssandra team and am very happy to hear that you like our
> management API design.
> Looking at the CEP, I see that your current target design mentions the
> k8ssandra-management-api.
> What do you have in mind specifically there? Do you plan on rewriting a
> brand new implementation which would be partially inspired by our agent? Or
> would the project integrate our agent code in-tree or as a dependency?
> The latter would require of course changes to remove the CQL interceptor
> and run the queries naturally against Cassandra, along with extracting just
> the agent without the REST server.
> The former suggests that we'd have to modify our REST server to interact
> with the newly developed agent from the Cassandra project.
>
> For the metrics, we were using MCAC
>  so
> far in the K8ssandra project but the use of collectd (while very convenient
> for non kubernetes use cases) and the design issues it created led us to
> build a metrics endpoint directly into the management api which hooks on to
> the metrics registry, and is out of the box scrapable by Prometheus. As you
> mentioned, it also allows us to extend the set of metrics easily, which
> we've done recently to expose running compactions and streams as metrics.
> It is also very efficient compared to JMX based alternatives.
>
> Let us know how we can help move this CEP forward as we're willing to
> participate.
> I think it would be great to have a single api that could be used by all
> sidecars, may they be custom or officially supported by the project.
>
> Cheers,
>
> Alex
>
> Le mar. 28 nov. 2023 à 01:00, Francisco Guerrero  a
> écrit :
>
>> Hi Maxim,
>>
>> Thanks for working on this CEP!
>>
>> The CEP addresses some of the features we have been discussing for
>> Cassandra Sidecar. For example, a dedicated admin port, moving towards more
>> CQL-like interfacing with Cassandra, among others.
>>
>> I think virtual tables intended to bring the gap down between JMX and
>> CQL. However, virtual tables cannot action on node operations, so CEP-38 is
>> finally addressing that gap.
>>
>> I look forward to collaborating in this CEP, I think Cassandra and its
>> ecosystem will greatly benefit from this enhancement.
>>
>> Best,
>> - Francisco
>>
>> On 2023/11/13 18:08:54 Maxim Muzafarov wrote:
>> > Hello everyone,
>> >
>> > While we are still waiting for the review to make the settings virtual
>> > table updatable (CASSANDRA-15254), which will improve the
>> > configuration management experience for users, I'd like to take
>> > another step forward and improve the C* management approach we have as
>> > a whole. This approach aims to make all Cassandra management commands
>> > accessible via CQL, but not only that.
>> >
>> > The problem of making commands accessible via CQL presents a complex
>> > challenge, especially if we aim to minimize code duplication across
>> > the implementation of management operations for different APIs and
>> > reduce the overall maintenance burden. The proposal's scope goes
>> > beyond simply introducing a new CQL syntax. It encompasses several key
>> > objectives for C* management operations, beyond their availability
>> > through CQL:

[RELEASE] Apache Cassandra 5.0-beta1 released

[Mick Semb Wever]

The Cassandra team is pleased to announce the release of Apache Cassandra
version 5.0-beta1.

Apache Cassandra is a fully distributed database. It is the right choice
when you need scalability and high availability without compromising
performance.

Downloads of source and binary distributions are listed in our download
section:

 http://cassandra.apache.org/download/

This version is a beta release[1] on the 5.0 series. As always, please pay
attention to the release notes[2] and let us know[3] if you were to
encounter any problem.

Please note what our definition of a beta release means, further info at
https://cwiki.apache.org/confluence/display/CASSANDRA/Release+Lifecycle

For more information on what's in 5.0:
https://cassandra.apache.org/_/Apache-Cassandra-5.0-Moving-Toward-an-AI-Driven-Future.html


Enjoy!

[1]: CHANGES.txt
https://github.com/apache/cassandra/blob/cassandra-5.0-beta1/CHANGES.txt
[2]: NEWS.txt
https://github.com/apache/cassandra/blob/cassandra-5.0-beta1/NEWS.txt
[3]: https://issues.apache.org/jira/browse/CASSANDRA

Re: [DISCUSSION] CEP-38: CQL Management API

[Abe Ratnofsky]

Adding to Hari's comments:

> Any changes expected at client/driver side? While using JMX/nodetool, it is 
> clear that the command/operations are getting executed against which 
> Cassandra node. But a client can connect to multiple hosts and trigger 
> queries, then how can it ensure that commands are executed against the 
> desired Cassandra instance?

Clients are expected to set the node for the given CQL statement in cases like 
this; see docstring for example: 
https://github.com/apache/cassandra-java-driver/blob/4.x/core/src/main/java/com/datastax/oss/driver/api/core/cql/Statement.java#L124-L147

> The term COMMAND is a bit abstract I feel (subjective). Some of the examples 
> quoted are referring to updating settings (for example: EXECUTE COMMAND 
> setconcurrentcompactors WITH concurrent_compactors=5;) and some are referring 
> to operations. Updating settings and running operations are considerably 
> different things. They may have to be handled in their own way. And I also 
> feel the settings part is overlapping with virtual tables. If virtual tables 
> support writes (at least the settings virtual table), then settings can be 
> updated using the virtual table itself.

I agree with this - I actually think it would be clearer if this was referred 
to as nodetool, if the set of commands is going to be largely based on nodetool 
at the beginning. There is a lot of documentation online that references 
nodetool by name, and changing the nomenclature would make that existing 
documentation harder to understand. If a user can understand this as "nodetool, 
but better and over CQL not JMX" I think that's a clearer transition than a new 
concept of "commands".

I understand that this proposal includes more than just nodetool, but there's a 
benefit to having a tool with a name, and a web search for "cassandra commands" 
is going to have more competition and ambiguity.

Voice of Apache (Feathercast) at summit?

[Rich Bowen]

Hey, folks. I'll be at Cassandra Summit next week, and was wondering if any of 
you who might be there would be interested in doing a podcast interview with me 
for Voice Of Apache (the podcast formerly known as Feathercast - see 
https://feathercast.apache.org for context). Topics might include something 
about 5.0, retrospectives on the last 13 years, or whatever you think might be 
of interest.

Let me know soon of anyone's interested/available, so I know to pack my gear.

Thanks!

--Rich

[CMWG] December 6 Meeting

[Melissa Logan]

Tomorrow is the last Cassandra Marketing Working Group meeting of the year!
Join us at *8:00am PT / 4:00pm UTC, Wednesday Dec. 6*.

Agenda below. If you have something to add, please do so here
.
Details and how to join are in the document.

Agenda

   -

   Cassandra Summit 
   + AI.Dev 
   -

   Catalyst program launched!
   -

  https://cassandra.apache.org/_/cassandra-catalyst-program.html
  -

  Nominate someone or apply
  

  -

   Should we keep using X?


Ways to Participate

   -

   Social media promotions
   

   -

   Cassandra Catalyst program
   


Upcoming

   -

   12-13 December Cassandra Summit
   , San Jose
   -

   3 January CMWG
   -

   25 January Town Hall - AI Panel with Jon Haddad, Dinesh Joshi (others
   pending)
   -

   30 January Contributor Meeting - CEP-38 with Maxim Muzafarov


Melissa