Re: [DISCUSS] Feature branch to update a nodetool obsolete dependency (airline)

[Štefan Miklošovič]

Hi Maxim,

thank you for doing this. I think that Picocli is a great choice, comparing
it with airline v2 which is an attempt to resurrect the original airline,
it seems to be way more active and popular.

I personally don't have anything against what you suggested, however I
think that this kind of work will put additional stress on us being sure
that the output of the commands will be exactly as it is now. We do have
nodetool tests which are covering the tests for the output which is very
handy in this kind of situation, but I think we do not test all of them. It
would be great to increase our test coverage where possible in this area
and I think it is actually going to be a requirement as only then we will
be sure that old and new code produces the same output.

I think it is too soon to contemplate when we switch to this, we just need
to be sure that it is the same so existing integrations will not be broken.

Regards

On Fri, Jun 28, 2024 at 3:48 PM Maxim Muzafarov  wrote:

> Hello everyone,
>
>
> The nodetool relies on the airlift/airline library to mark up the CLI
> commands used to manage Cassandra, which are part of our public API.
> This library is no longer maintained, so we need to update it anyway,
> and the good news is that we already have several good alternatives:
> airline-2 [3] or picocli [2].
>
> In this message, I'm mainly talking about CASSANDRA-17445 [4], which
> refers to the problem and is a prerequisite for a larger CEP-38 CQL
> Management API [5]. It doesn't make sense to use annotations from the
> deprecated library to build a new API, so this is another reason to
> update the library as soon as possible and do some inherently small
> code refactoring required for the CEP-38.
>
> In addition to being widely used and well supported, the Picocli
> library offers the following advantages for us:
> - We can detach the jmx-specific parameters from the commands so that
> they can be reused in other APIs (e.g. without host, port) while
> remaining backwards compatible;
> - We can set up nodetool's autocompletion after the migration with
> minimal effort;
> - There is a good Picocli ecosystem of tools that we can use to
> simplify our codebase, e.g. generate man pages tool to make our CLIs
> more Unix friendly [7];
>
>
> = Prototype =
>
> I have a working prototype [8] that shows what the result will look
> like. The prototype includes:
> - Tests between the execution of commands via the nodetool and nodtoolv2;
> - 5 out of 164 nodetool commands have been moved so far, to show the
> refactoring we need to do to the command's body;
> - The command help output under for the nodetoolv2 is the same as it
> is currently for the nodetool and this is the default, however a
> "cassandra.cli.picocli.layout" is added to switch to the Picocli
> defaults;
> - You can also see that the colour scheme is applied by the Picocli
> out of the box, and this is how it looks [9];
> - The nodetoolv2 is called first when the shell is triggered, and if
> the nodetoolv2 doesn't contain the command it needs yet, it falls back
> to the nodetool and the old argument parser;
>
>
> Since the number of commands is quite large (164), I'd like to create
> a feature branch and move all the commands one at a time, while
> keeping the output backwards by applying additional tests at the same
> time and checking that the CI is always green. I think the "feature
> branch" approach will be less stressful for us since it focuses on
> requiring a review of only tedious changes to the feature branch,
> rather than reviewing the 15k line patch.
>
>
> Anyway, I am open to any suggestions and advice based on your
> experience and best practices for this case. Looking forward to your
> thoughts and suggestions.
>
>
>
> [1] https://github.com/airlift/airline
> [2] https://picocli.info/
> [3] https://github.com/rvesse/airline
> [4] https://issues.apache.org/jira/browse/CASSANDRA-17445
> [5]
> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-38%3A+CQL+Management+API
> [6]
> https://github.com/apache/cassandra/pull/2497/files#diff-acdd5f29d28df5c02f4bfc933528f084508b4923112e312e68a4aff7df973bce
> [7] https://picocli.info/man/gen-manpage.html
> [8] https://github.com/apache/cassandra/pull/2497/files
> [9]
> https://github.com/apache/cassandra/assets/3415046/57b14ae0-ff59-43d2-b542-10d3218ae075
>

Re: [DISCUSS] CEP-42: Constraints Framework

[Bernardo Botella]

Thanks everyone for all the feedback that came in after the call for votes.

To Yifan's point, yes you are right, and I updated the CEP with the expressions.

There’s been a really good discussion around adding or supporting constraints 
at read time. I think the point Doug made illustrate that such constraints may 
come with rough edges that have other implications that need be taken care of. 
Due to that, I’d like to follow Dinesh’s suggestion of deferring it, and start 
again with the call for votes for the proposal. 

I will resurface the call for votes thread.

Thanks everyone!
Bernardo

> On Jun 29, 2024, at 1:26 PM, Dinesh Joshi  wrote:
> 
> The read time constraint application is going to be expensive and possibly 
> complicated to implement with low RoI. Therefore my suggestion is to defer 
> it. If there are situations where it appears to be helpful, we can always 
> reconsider it.
> 
> On Tue, Jun 25, 2024 at 3:34 PM Yifan Cai  > wrote:
>>> - Alter and Drop constraints are as follows
>>> ALTER CONSTRAINT [name] CHECK new_condition DROP CONSTRAINT [name]
>> 
>> I think you mean the following syntax to modify existing constraints, since 
>> constraints are part of the table definition. 
>> ALTER TABLE [keyspace_name.]table_name ALTER CONSTRAINT [constraint_name] 
>> CHECK check_expression
>> 
>> Dinesh's proposal to check on read is a good addition. I think it is 
>> optional and should be enabled/disabled w/ configuration. The extra check 
>> may not be desirable in some circumstances, e.g. the use cases do not ever 
>> change the constraints and do not have other write data other than CQL. 
>> Since the original CEP defines that the constraints are applied at the write 
>> time, we need to update the CEP if we decide to include the check on read.
>> 
>> - Yifan
>> 
>> 
>> On Tue, Jun 25, 2024 at 1:13 PM Štefan Miklošovič > > wrote:
>>> I wonder how often it is that users will apply the constraints on tables 
>>> with data while they know their data is probably not compliant with the 
>>> constraint configuration. I humbly think that people are aware of this in 
>>> advance and what usually happens is that there is some kind of a job which 
>>> consolidates the data (or migrates them to a new table) before admins put a 
>>> "lid" on that so moving forward nobody puts there anything which would 
>>> violate it.
>>> 
>>> I probably have not kept myself up to date with the discussion but I was 
>>> thinking that constraints are effectively there just on the write path. 
>>> Whatever is read is not a job of a constraint to refuse to return.
>>> 
>>> On Tue, Jun 25, 2024 at 9:57 PM Dinesh Joshi >> > wrote:
 Abe, that's a good point. We need to call out distinct use-cases here. 
 When a fresh cluster is set up with constraints we don't have any issues 
 because the data written and read back is going to be compliant to the 
 constraint(s). For existing data in a cluster where new constraints are 
 applied or existing constraints changed in such a way that may render 
 existing data unreadable, we need a good user experience. This is what I 
 propose –
 
 1. When a constraint is added or changed in such a way that existing data 
 could be rendered unreadable, we should warn the user.
 
 2. Give the user a choice of whether it is ok for the data to be rendered 
 unreadable and an error is issued or a warning should be issued when the 
 read violates the constraint but data is still readable. New data going in 
 will meet the constraint but old data would need to be rewritten for the 
 application to make it compliant.
 
 With this approach the application developer can decide what is right for 
 their particular use-case. In many cases the application developer may 
 decide to rewrite the data when they see a warning.
 
 
 On Tue, Jun 25, 2024 at 12:46 PM Abe Ratnofsky >>> > wrote:
> If we're going to introduce a feature that looks like SQL constraints, we 
> should make sure it's "reasonably" compliant. In particular, we should 
> avoid situations where a user creates a constraint, writes some data, 
> then reads data that violates that constraint, unless they've expressed 
> that violations on read would be acceptable.
> 
> For Postgres, when adding a new constraint you can specify NOT VALID to 
> avoid scanning all existing relevant data[1]. If we want to avoid 
> scan-on-DDL, this tradeoff needs to be made clear to a user.
> 
> As we've already discussed, constraints must deal with operations that 
> appear within limits on the write path, but once reconciled on read or 
> during compaction can lead to a violation. Adding to non-frozen 
> collections is one example. Expecting users to understand the write path 
> for collections feels unrealistic t

Re: [VOTE] Release Apache Cassandra 5.0-rc1

[Claude Warren, Jr via dev]

Perhaps we should consider a Milestone release.  At least in some projects
this is a way to provide a test bed with known issues that will be
corrected before an RC.

On Sun, Jun 30, 2024 at 9:50 PM Jon Haddad  wrote:

> This came in after our vote, but we might also have a problem with
> performing schema changes after a full restart.  Appears to only be if the
> entire cluster was shut down, according to the report.  If it's true, this
> might affect anyone trying to restore from a backup.  This would also be a
> blocker for me, if that's the case.
>
> https://issues.apache.org/jira/browse/CASSANDRA-19735
>
> Jon
>
>
> On Thu, Jun 27, 2024 at 9:49 PM Jon Haddad  wrote:
>
>> Thanks for confirming this, Blake. I agree that we should not knowingly
>> ship new versions with severe bugs that cause the DB to crash, regression
>> or not.
>>
>> -1 from me as well
>>
>>
>> On Fri, Jun 28, 2024 at 1:39 AM Blake Eggleston 
>> wrote:
>>
>>> Looking at the ticket, I’d say Jon’s concern is legitimate. The
>>> segfaults Jon is seeing are probably caused by paxos V2 when combined with
>>> off heap memtables for the reason Benedict suggests in the JIRA. This
>>> problem will continue to exist in 5.0. Unfortunately, it looks like the
>>> patch posted is not enough to address the issue and will need to be a bit
>>> more involved to properly fix the problem.
>>>
>>> While this is not a regression, I think Jon’s point about trie memtables
>>> increasing usage of off heap memtables is a good one, and anyway we
>>> shouldn’t be doing major releases with known process crashing bugs.
>>>
>>> So I’m voting -1 on this release and will work with Jon and Benedict to
>>> get this fixed.
>>>
>>> Thanks,
>>>
>>> Blake
>>>
>>>
>>> On Jun 26, 2024, at 6:47 AM, Josh McKenzie  wrote:
>>>
>>> Blake or Benedict - can either of you speak to Jon's concerns around
>>> CASSANDRA-19668?
>>>
>>> On Wed, Jun 26, 2024, at 12:18 AM, Jeff Jirsa wrote:
>>>
>>>
>>> +1
>>>
>>>
>>>
>>> On Jun 25, 2024, at 5:04 AM, Mick Semb Wever  wrote:
>>>
>>> 
>>>
>>> Proposing the test build of Cassandra 5.0-rc1 for release.
>>>
>>> sha1: b43f0b2e9f4cb5105764ef9cf4ece404a740539a
>>> Git: https://github.com/apache/cassandra/tree/5.0-rc1-tentative
>>> Maven Artifacts:
>>> https://repository.apache.org/content/repositories/orgapachecassandra-1336/org/apache/cassandra/cassandra-all/5.0-rc1/
>>>
>>> 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-rc1/
>>>
>>> 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-rc1-tentative/CHANGES.txt
>>> [2]: NEWS.txt:
>>> https://github.com/apache/cassandra/blob/5.0-rc1-tentative/NEWS.txt
>>>
>>>
>>>

Re: [DISCUSS] Feature branch to update a nodetool obsolete dependency (airline)

[Bernardo Botella]

+1 on the feature branch allowing breaking the effort into smaller chunks that 
can be even worked in parallel.



> On Jul 1, 2024, at 3:13 AM, Štefan Miklošovič  wrote:
> 
> Hi Maxim,
> 
> thank you for doing this. I think that Picocli is a great choice, comparing 
> it with airline v2 which is an attempt to resurrect the original airline, it 
> seems to be way more active and popular.
> 
> I personally don't have anything against what you suggested, however I think 
> that this kind of work will put additional stress on us being sure that the 
> output of the commands will be exactly as it is now. We do have nodetool 
> tests which are covering the tests for the output which is very handy in this 
> kind of situation, but I think we do not test all of them. It would be great 
> to increase our test coverage where possible in this area and I think it is 
> actually going to be a requirement as only then we will be sure that old and 
> new code produces the same output.
> 
> I think it is too soon to contemplate when we switch to this, we just need to 
> be sure that it is the same so existing integrations will not be broken.
> 
> Regards 
> 
> On Fri, Jun 28, 2024 at 3:48 PM Maxim Muzafarov  > wrote:
>> Hello everyone,
>> 
>> 
>> The nodetool relies on the airlift/airline library to mark up the CLI
>> commands used to manage Cassandra, which are part of our public API.
>> This library is no longer maintained, so we need to update it anyway,
>> and the good news is that we already have several good alternatives:
>> airline-2 [3] or picocli [2].
>> 
>> In this message, I'm mainly talking about CASSANDRA-17445 [4], which
>> refers to the problem and is a prerequisite for a larger CEP-38 CQL
>> Management API [5]. It doesn't make sense to use annotations from the
>> deprecated library to build a new API, so this is another reason to
>> update the library as soon as possible and do some inherently small
>> code refactoring required for the CEP-38.
>> 
>> In addition to being widely used and well supported, the Picocli
>> library offers the following advantages for us:
>> - We can detach the jmx-specific parameters from the commands so that
>> they can be reused in other APIs (e.g. without host, port) while
>> remaining backwards compatible;
>> - We can set up nodetool's autocompletion after the migration with
>> minimal effort;
>> - There is a good Picocli ecosystem of tools that we can use to
>> simplify our codebase, e.g. generate man pages tool to make our CLIs
>> more Unix friendly [7];
>> 
>> 
>> = Prototype =
>> 
>> I have a working prototype [8] that shows what the result will look
>> like. The prototype includes:
>> - Tests between the execution of commands via the nodetool and nodtoolv2;
>> - 5 out of 164 nodetool commands have been moved so far, to show the
>> refactoring we need to do to the command's body;
>> - The command help output under for the nodetoolv2 is the same as it
>> is currently for the nodetool and this is the default, however a
>> "cassandra.cli.picocli.layout" is added to switch to the Picocli
>> defaults;
>> - You can also see that the colour scheme is applied by the Picocli
>> out of the box, and this is how it looks [9];
>> - The nodetoolv2 is called first when the shell is triggered, and if
>> the nodetoolv2 doesn't contain the command it needs yet, it falls back
>> to the nodetool and the old argument parser;
>> 
>> 
>> Since the number of commands is quite large (164), I'd like to create
>> a feature branch and move all the commands one at a time, while
>> keeping the output backwards by applying additional tests at the same
>> time and checking that the CI is always green. I think the "feature
>> branch" approach will be less stressful for us since it focuses on
>> requiring a review of only tedious changes to the feature branch,
>> rather than reviewing the 15k line patch.
>> 
>> 
>> Anyway, I am open to any suggestions and advice based on your
>> experience and best practices for this case. Looking forward to your
>> thoughts and suggestions.
>> 
>> 
>> 
>> [1] https://github.com/airlift/airline
>> [2] https://picocli.info/
>> [3] https://github.com/rvesse/airline
>> [4] https://issues.apache.org/jira/browse/CASSANDRA-17445
>> [5] 
>> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-38%3A+CQL+Management+API
>> [6] 
>> https://github.com/apache/cassandra/pull/2497/files#diff-acdd5f29d28df5c02f4bfc933528f084508b4923112e312e68a4aff7df973bce
>> [7] https://picocli.info/man/gen-manpage.html
>> [8] https://github.com/apache/cassandra/pull/2497/files
>> [9] 
>> https://github.com/apache/cassandra/assets/3415046/57b14ae0-ff59-43d2-b542-10d3218ae075

Re: [VOTE] CEP-42: Constraints Framework

[Bernardo Botella]

With all the feedback that came in the discussion thread after the call for 
votes, I’d like to extend the period another 72 hours starting today.

As before, a vote passes if there are at least 3 binding +1s and no binding 
vetoes.

Thanks,
Bernardo Botella

> On Jun 24, 2024, at 7:17 AM, Bernardo Botella  
> wrote:
> 
> Hi everyone,
> 
> I would like to start the voting for CEP-42.
> 
> Proposal: 
> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-42%3A+Constraints+Framework
> Discussion: https://lists.apache.org/thread/xc2phmxgsc7t3y9b23079vbflrhyyywj
> 
> The vote will be open for 72 hours. A vote passes if there are at least 3 
> binding +1s and no binding vetoes.
> 
> Thanks,
> Bernardo Botella

Re: [VOTE] Release Apache Cassandra 5.0-rc1

[Josh McKenzie]

> Perhaps we should consider a Milestone release.  At least in some projects 
> this is a way to provide a test bed with known issues that will be corrected 
> before an RC.
How does that differ from beta in our lifecycle? API stable but a test bed to 
suss out issues like this.


On Mon, Jul 1, 2024, at 9:30 AM, Claude Warren, Jr via dev wrote:
> Perhaps we should consider a Milestone release.  At least in some projects 
> this is a way to provide a test bed with known issues that will be corrected 
> before an RC.
> 
> On Sun, Jun 30, 2024 at 9:50 PM Jon Haddad  wrote:
>> This came in after our vote, but we might also have a problem with 
>> performing schema changes after a full restart.  Appears to only be if the 
>> entire cluster was shut down, according to the report.  If it's true, this 
>> might affect anyone trying to restore from a backup.  This would also be a 
>> blocker for me, if that's the case.
>> 
>> https://issues.apache.org/jira/browse/CASSANDRA-19735
>> 
>> Jon
>> 
>> 
>> On Thu, Jun 27, 2024 at 9:49 PM Jon Haddad  wrote:
>>> Thanks for confirming this, Blake. I agree that we should not knowingly 
>>> ship new versions with severe bugs that cause the DB to crash, regression 
>>> or not. 
>>> 
>>> -1 from me as well
>>> 
>>> 
>>> On Fri, Jun 28, 2024 at 1:39 AM Blake Eggleston  
>>> wrote:
 Looking at the ticket, I’d say Jon’s concern is legitimate. The segfaults 
 Jon is seeing are probably caused by paxos V2 when combined with off heap 
 memtables for the reason Benedict suggests in the JIRA. This problem will 
 continue to exist in 5.0. Unfortunately, it looks like the patch posted is 
 not enough to address the issue and will need to be a bit more involved to 
 properly fix the problem.
 
 While this is not a regression, I think Jon’s point about trie memtables 
 increasing usage of off heap memtables is a good one, and anyway we 
 shouldn’t be doing major releases with known process crashing bugs.
 
 So I’m voting -1 on this release and will work with Jon and Benedict to 
 get this fixed.
 
 Thanks,
 
 Blake
 
 
> On Jun 26, 2024, at 6:47 AM, Josh McKenzie  wrote:
> 
> Blake or Benedict - can either of you speak to Jon's concerns around 
> CASSANDRA-19668?
> 
> On Wed, Jun 26, 2024, at 12:18 AM, Jeff Jirsa wrote:
>> 
>> +1
>> 
>> 
>> 
>>> On Jun 25, 2024, at 5:04 AM, Mick Semb Wever  wrote:
>>> 
>>> 
>>> Proposing the test build of Cassandra 5.0-rc1 for release.
>>> 
>>> sha1: b43f0b2e9f4cb5105764ef9cf4ece404a740539a
>>> Git: https://github.com/apache/cassandra/tree/5.0-rc1-tentative
>>> Maven Artifacts: 
>>> https://repository.apache.org/content/repositories/orgapachecassandra-1336/org/apache/cassandra/cassandra-all/5.0-rc1/
>>> 
>>> 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-rc1/
>>> 
>>> 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-rc1-tentative/CHANGES.txt
>>> [2]: NEWS.txt: 
>>> https://github.com/apache/cassandra/blob/5.0-rc1-tentative/NEWS.txt

Re: [DISCUSS] Feature branch to update a nodetool obsolete dependency (airline)

[Jon Haddad]

> I personally don't have anything against what you suggested, however I
think that this kind of work will put additional stress on us being sure
that the output of the commands will be exactly as it is now. We do have
nodetool tests which are covering the tests for the output which is very
handy in this kind of situation, but I think we do not test all of them. It
would be great to increase our test coverage where possible in this area
and I think it is actually going to be a requirement as only then we will
be sure that old and new code produces the same output.

I'm not familiar with picocli, only jcommander, however I don't think
keeping the output consistent should be a problem as long as it's a similar
programming model.

I also don't think keeping the output consistent needs to be a strict long
term requirement.  We *should* have either a JSON output option for every
command, or a virtual table for structured data.  I don't remember us ever
making a promise that human readable tools would keep consistent across
major versions.


On Mon, Jul 1, 2024 at 6:44 AM Bernardo Botella <
conta...@bernardobotella.com> wrote:

> +1 on the feature branch allowing breaking the effort into smaller chunks
> that can be even worked in parallel.
>
>
>
> On Jul 1, 2024, at 3:13 AM, Štefan Miklošovič 
> wrote:
>
> Hi Maxim,
>
> thank you for doing this. I think that Picocli is a great choice,
> comparing it with airline v2 which is an attempt to resurrect the original
> airline, it seems to be way more active and popular.
>
> I personally don't have anything against what you suggested, however I
> think that this kind of work will put additional stress on us being sure
> that the output of the commands will be exactly as it is now. We do have
> nodetool tests which are covering the tests for the output which is very
> handy in this kind of situation, but I think we do not test all of them. It
> would be great to increase our test coverage where possible in this area
> and I think it is actually going to be a requirement as only then we will
> be sure that old and new code produces the same output.
>
> I think it is too soon to contemplate when we switch to this, we just need
> to be sure that it is the same so existing integrations will not be broken.
>
> Regards
>
> On Fri, Jun 28, 2024 at 3:48 PM Maxim Muzafarov  wrote:
>
>> Hello everyone,
>>
>>
>> The nodetool relies on the airlift/airline library to mark up the CLI
>> commands used to manage Cassandra, which are part of our public API.
>> This library is no longer maintained, so we need to update it anyway,
>> and the good news is that we already have several good alternatives:
>> airline-2 [3] or picocli [2].
>>
>> In this message, I'm mainly talking about CASSANDRA-17445 [4], which
>> refers to the problem and is a prerequisite for a larger CEP-38 CQL
>> Management API [5]. It doesn't make sense to use annotations from the
>> deprecated library to build a new API, so this is another reason to
>> update the library as soon as possible and do some inherently small
>> code refactoring required for the CEP-38.
>>
>> In addition to being widely used and well supported, the Picocli
>> library offers the following advantages for us:
>> - We can detach the jmx-specific parameters from the commands so that
>> they can be reused in other APIs (e.g. without host, port) while
>> remaining backwards compatible;
>> - We can set up nodetool's autocompletion after the migration with
>> minimal effort;
>> - There is a good Picocli ecosystem of tools that we can use to
>> simplify our codebase, e.g. generate man pages tool to make our CLIs
>> more Unix friendly [7];
>>
>>
>> = Prototype =
>>
>> I have a working prototype [8] that shows what the result will look
>> like. The prototype includes:
>> - Tests between the execution of commands via the nodetool and nodtoolv2;
>> - 5 out of 164 nodetool commands have been moved so far, to show the
>> refactoring we need to do to the command's body;
>> - The command help output under for the nodetoolv2 is the same as it
>> is currently for the nodetool and this is the default, however a
>> "cassandra.cli.picocli.layout" is added to switch to the Picocli
>> defaults;
>> - You can also see that the colour scheme is applied by the Picocli
>> out of the box, and this is how it looks [9];
>> - The nodetoolv2 is called first when the shell is triggered, and if
>> the nodetoolv2 doesn't contain the command it needs yet, it falls back
>> to the nodetool and the old argument parser;
>>
>>
>> Since the number of commands is quite large (164), I'd like to create
>> a feature branch and move all the commands one at a time, while
>> keeping the output backwards by applying additional tests at the same
>> time and checking that the CI is always green. I think the "feature
>> branch" approach will be less stressful for us since it focuses on
>> requiring a review of only tedious changes to the feature branch,
>> rather than reviewing the 15k line patch.

Re: [DISCUSS] Feature branch to update a nodetool obsolete dependency (airline)

[Brandon Williams]

On Mon, Jul 1, 2024 at 12:30 PM Jon Haddad  wrote:
>
> I also don't think keeping the output consistent needs to be a strict long 
> term requirement.  We *should* have either a JSON output option for every 
> command, or a virtual table for structured data.  I don't remember us ever 
> making a promise that human readable tools would keep consistent across major 
> versions.
>

We discussed this a bit here:
https://lists.apache.org/thread/72j5qfgbttjcmylhcmfq1ptboh641ns0

Kind Regards,
Brandon

Re: [DISCUSS] Feature branch to update a nodetool obsolete dependency (airline)

[Štefan Miklošovič]

Oh yes ... THAT thread. Everytime I want to change the output of a nodetool
command, it is a never-ending story of running in circles if we can do
that. My perception is that we are very sensitive to what it looks like and
that we are not breaking it. Addition is mostly fine but god forbid when
something is going to be changed. I think we settled with changing it in
majors is probably OK but the hard requirement is to have a corresponding
JSON output.

On Mon, Jul 1, 2024 at 7:37 PM Brandon Williams  wrote:

> On Mon, Jul 1, 2024 at 12:30 PM Jon Haddad  wrote:
> >
> > I also don't think keeping the output consistent needs to be a strict
> long term requirement.  We *should* have either a JSON output option for
> every command, or a virtual table for structured data.  I don't remember us
> ever making a promise that human readable tools would keep consistent
> across major versions.
> >
>
> We discussed this a bit here:
> https://lists.apache.org/thread/72j5qfgbttjcmylhcmfq1ptboh641ns0
>
> Kind Regards,
> Brandon
>

Re: [DISCUSS] Feature branch to update a nodetool obsolete dependency (airline)

[Dinesh Joshi]

I don't personally think there is a strong need for a feature branch. If it
makes it easy for you, please go ahead with a feature branch.

One thing I had raised in the past was the desire to have a flag that would
generate machine readable output for nodetool commands. If this can be done
with a minor incremental effort, it would definitely reduce the burden on
operators / integrations that rely on the nodetool output. As I have
earlier indicated in the past, relying on human readable output for CLI
tools like nodetool is fragile and providing a JSON output as an
alternative is a great first step in eliminating that dependency. I'm just
curious about the level of effort. If it is too much or too invasive, we
can consider producing JSON output for inclusion in the next major release.

On Fri, Jun 28, 2024 at 6:47 AM Maxim Muzafarov  wrote:

> Hello everyone,
>
>
> The nodetool relies on the airlift/airline library to mark up the CLI
> commands used to manage Cassandra, which are part of our public API.
> This library is no longer maintained, so we need to update it anyway,
> and the good news is that we already have several good alternatives:
> airline-2 [3] or picocli [2].
>
> In this message, I'm mainly talking about CASSANDRA-17445 [4], which
> refers to the problem and is a prerequisite for a larger CEP-38 CQL
> Management API [5]. It doesn't make sense to use annotations from the
> deprecated library to build a new API, so this is another reason to
> update the library as soon as possible and do some inherently small
> code refactoring required for the CEP-38.
>
> In addition to being widely used and well supported, the Picocli
> library offers the following advantages for us:
> - We can detach the jmx-specific parameters from the commands so that
> they can be reused in other APIs (e.g. without host, port) while
> remaining backwards compatible;
> - We can set up nodetool's autocompletion after the migration with
> minimal effort;
> - There is a good Picocli ecosystem of tools that we can use to
> simplify our codebase, e.g. generate man pages tool to make our CLIs
> more Unix friendly [7];
>
>
> = Prototype =
>
> I have a working prototype [8] that shows what the result will look
> like. The prototype includes:
> - Tests between the execution of commands via the nodetool and nodtoolv2;
> - 5 out of 164 nodetool commands have been moved so far, to show the
> refactoring we need to do to the command's body;
> - The command help output under for the nodetoolv2 is the same as it
> is currently for the nodetool and this is the default, however a
> "cassandra.cli.picocli.layout" is added to switch to the Picocli
> defaults;
> - You can also see that the colour scheme is applied by the Picocli
> out of the box, and this is how it looks [9];
> - The nodetoolv2 is called first when the shell is triggered, and if
> the nodetoolv2 doesn't contain the command it needs yet, it falls back
> to the nodetool and the old argument parser;
>
>
> Since the number of commands is quite large (164), I'd like to create
> a feature branch and move all the commands one at a time, while
> keeping the output backwards by applying additional tests at the same
> time and checking that the CI is always green. I think the "feature
> branch" approach will be less stressful for us since it focuses on
> requiring a review of only tedious changes to the feature branch,
> rather than reviewing the 15k line patch.
>
>
> Anyway, I am open to any suggestions and advice based on your
> experience and best practices for this case. Looking forward to your
> thoughts and suggestions.
>
>
>
> [1] https://github.com/airlift/airline
> [2] https://picocli.info/
> [3] https://github.com/rvesse/airline
> [4] https://issues.apache.org/jira/browse/CASSANDRA-17445
> [5]
> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-38%3A+CQL+Management+API
> [6]
> https://github.com/apache/cassandra/pull/2497/files#diff-acdd5f29d28df5c02f4bfc933528f084508b4923112e312e68a4aff7df973bce
> [7] https://picocli.info/man/gen-manpage.html
> [8] https://github.com/apache/cassandra/pull/2497/files
> [9]
> https://github.com/apache/cassandra/assets/3415046/57b14ae0-ff59-43d2-b542-10d3218ae075
>

Re: [VOTE] CEP-42: Constraints Framework

[Ariel Weisberg]

Hi,

I am +1 on CEP-42 with the latest updates to the CEP to clarify syntax, error 
messages, constraint naming and generated naming, alter/drop, describe etc.

I think this now tracks very closely to how other SQL databases define 
constraints and the syntax is easily extensible to multi-column and multi-table 
constraints.

Ariel

On Mon, Jul 1, 2024, at 9:48 AM, Bernardo Botella wrote:
> With all the feedback that came in the discussion thread after the call for 
> votes, I’d like to extend the period another 72 hours starting today.
> 
> As before, a vote passes if there are at least 3 binding +1s and no binding 
> vetoes.
> 
> Thanks,
> Bernardo Botella
> 
>> On Jun 24, 2024, at 7:17 AM, Bernardo Botella  
>> wrote:
>> 
>> Hi everyone,
>> 
>> I would like to start the voting for CEP-42.
>> 
>> Proposal: 
>> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-42%3A+Constraints+Framework
>> Discussion: https://lists.apache.org/thread/xc2phmxgsc7t3y9b23079vbflrhyyywj
>> 
>> The vote will be open for 72 hours. A vote passes if there are at least 3 
>> binding +1s and no binding vetoes.
>> 
>> Thanks,
>> Bernardo Botella

Re: [VOTE] CEP-42: Constraints Framework

[Dinesh Joshi]

+1

On Mon, Jul 1, 2024 at 11:58 AM Ariel Weisberg  wrote:

> Hi,
>
> I am +1 on CEP-42 with the latest updates to the CEP to clarify syntax,
> error messages, constraint naming and generated naming, alter/drop,
> describe etc.
>
> I think this now tracks very closely to how other SQL databases define
> constraints and the syntax is easily extensible to multi-column and
> multi-table constraints.
>
> Ariel
>
> On Mon, Jul 1, 2024, at 9:48 AM, Bernardo Botella wrote:
>
> With all the feedback that came in the discussion thread after the call
> for votes, I’d like to extend the period another 72 hours starting today.
>
> As before, a vote passes if there are at least 3 binding +1s and no
> binding vetoes.
>
> Thanks,
> Bernardo Botella
>
> On Jun 24, 2024, at 7:17 AM, Bernardo Botella <
> conta...@bernardobotella.com> wrote:
>
> Hi everyone,
>
> I would like to start the voting for CEP-42.
>
> Proposal:
> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-42%3A+Constraints+Framework
> Discussion:
> https://lists.apache.org/thread/xc2phmxgsc7t3y9b23079vbflrhyyywj
>
> The vote will be open for 72 hours. A vote passes if there are at least 3
> binding +1s and no binding vetoes.
>
> Thanks,
> Bernardo Botella
>
>
>

Re: [VOTE] CEP-42: Constraints Framework

[Doug Rohrer]

+1 (nb) - Thanks for all of the suggestions and Bernardo for wrangling the CEP 
into shape!

Doug

> On Jul 1, 2024, at 3:06 PM, Dinesh Joshi  wrote:
> 
> +1
> 
> On Mon, Jul 1, 2024 at 11:58 AM Ariel Weisberg  > wrote:
>> Hi,
>> 
>> I am +1 on CEP-42 with the latest updates to the CEP to clarify syntax, 
>> error messages, constraint naming and generated naming, alter/drop, describe 
>> etc.
>> 
>> I think this now tracks very closely to how other SQL databases define 
>> constraints and the syntax is easily extensible to multi-column and 
>> multi-table constraints.
>> 
>> Ariel
>> 
>> On Mon, Jul 1, 2024, at 9:48 AM, Bernardo Botella wrote:
>>> With all the feedback that came in the discussion thread after the call for 
>>> votes, I’d like to extend the period another 72 hours starting today.
>>> 
>>> As before, a vote passes if there are at least 3 binding +1s and no binding 
>>> vetoes.
>>> 
>>> Thanks,
>>> Bernardo Botella
>>> 
 On Jun 24, 2024, at 7:17 AM, Bernardo Botella 
 mailto:conta...@bernardobotella.com>> wrote:
 
 Hi everyone,
 
 I would like to start the voting for CEP-42.
 
 Proposal: 
 https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-42%3A+Constraints+Framework
 Discussion: 
 https://lists.apache.org/thread/xc2phmxgsc7t3y9b23079vbflrhyyywj
 
 The vote will be open for 72 hours. A vote passes if there are at least 3 
 binding +1s and no binding vetoes.
 
 Thanks,
 Bernardo Botella
>>