Re: [DISCUSS] CASSANDRA-15234

[Ekaterina Dimitrova]

Hi everyone,

I have some good news and a bit of not that good but also not that bad.
CASSANDRA-15234 was committed last night, you will need to rebase CCM,
DTest and Trunk (if you use your own CCM and DTest branches). Push to
GitHub prior running CI should be in the order CCM -> DTest -> Trunk.
Unfortunately, we have new issues with CCM retagging (we solved different
ones but related before and things were working for some time
CASSANDRA-16688 )
and CircleCI. After retagging CCM it seems now CircleCI doesn't pick the
new tag and if you want to use CircleCI for testing, you will need to add
-e in requirements.txt:

-e git+https://github.com/riptano/ccm.git@cassandra-test#egg=ccm

The post-commit build in Jenkins looks fine, it picked up the new CCM tag.
I already have a ticket CASSANDRA-17351
. If anyone has any
ideas how to fix this permanently, all are welcome.

About CASSANDRA-15234, old and new yaml and format should both work.Further
to make it smoother for our users to migrate whenever they have time to the
new yaml, that gave us the chance also not to have to update the parameters
in the DTest suite but keep on exercising the old ones(one more way of
testing the backward compatibility too further to all new tests added). BUT
please, add any new tests using the new config so we can migrate in time.
You can find more details in the three primary classes Duration Spec,
DataStorageSpec and DataRateSpec (two of them are also extended, more
details in follow up tickets and posts) Backward compatibility is provided
through annotations used in Config.java. There is Converters enum to handle
different cases for backward compatibility.

Another rule is to start adding any new config with only the smallest
supported units.

I will explain and add full details in the docs I am already working on as
part of - CASSANDRA-17246
 I am planning also
on two posts - one for the users and one for us how to use the new
framework/format and what to expect.

Enjoy the rest of your weekend and apologise for the CircleCI temporary
inconvenience.

Bests regards,
Ekaterina

On Mon, 25 Oct 2021 at 10:19, Ekaterina Dimitrova 
wrote:

> Thank you Benedict.
>
> Considering there were no objections I am closing the discussion and
> getting back to work on the ticket itself. Thank you all. Have a great week
> ahead.
>
> On Wed, 20 Oct 2021 at 18:06, bened...@apache.org 
> wrote:
>
>> Thanks for moving this forwards Ekaterina.
>>
>> I think what we perhaps discovered is that there’s not really any
>> consensus about how to best do config files. I think in this situation it’s
>> best to defer to the one who’s actually putting in the time to _do_, so I
>> am more than happy to defer to your decisions.
>>
>> I’m sure everyone is looking forward to the improved consistency of this
>> work.
>>
>>
>> From: Ekaterina Dimitrova 
>> Date: Wednesday, 20 October 2021 at 22:27
>> To: dev@cassandra.apache.org 
>> Subject: Re: [DISCUSS] CASSANDRA-15234
>> Hi everyone,
>>
>> I think it is time to summarize the discussion.
>>
>> First of all, thank you for all the valuable input, suggestions, concerns,
>> and comments!
>>
>> The things that I believe we all agree on:
>>
>>-
>>
>>Simplicity for maintenance on our end - automation as much as possible
>>so we don’t have to maintain more than one configuration file and our
>>config is less prone to human errors while adding new features
>>-
>>
>>Simplicity for our users - as less confusing and as simple as possible
>>and having in mind the users’ toolset
>>-
>>
>>Simplicity for testing and verification of the different config file
>>formats
>>
>>
>> It seems to me that most people want to see committed both proposed
>> versions(feel free to correct me if I am wrong) with revision of the
>> default values and potentially commented out all parameters that are not
>> really mandatory to be changed. Also, versions with striped comments plus
>> a
>> way to maintain everything automatically, as much as possible.
>>
>> With that said it seems to me the current patch in CASSANDRA-15234 can be
>> committed after rebase and addressing any outstanding review comments. The
>> new version of cassandra.yaml, grouping the parameters can be added in a
>> new ticket by me or anyone with free cycles for that. It will require
>> additional work on the backward compatibility and the opportunity for
>> Cassandra to operate on all of the current versions but it will be new
>> additional opportunity which doesn’t disqualify the old ones so it seems
>> as
>> a fair game to be added at any point in time in the future as it won’t be
>> a
>> breaking change. We won’t replace anything. We will only add more options.
>>
>> If someone disagrees and wants to implement all possible options and
>> functionalities at once, I will be ha

Re: Build tool

[Dinesh Joshi]

We have spent a lot of time discussing this topic than actually trying to 
arrive at a decision.

Everyone has a strong opinion about which build tool the project should use. 
Each tool has its strengths and weaknesses. Today, `gradle` is the best tool 
for Java based projects in _my_ experience. Is it perfect? No.

Each tool will have some weaknesses and _all_ of them have a learning curve. 
However, 90% of our use-case is to add or change existing dependencies, 
producing artifacts and triggering test runs. For this most build tools are 
fine. They have a very tiny learning curve for these activities. The rest 10% 
is going to be complicated and will require research no matter what tool you 
end up picking. This is true for ant as well.

If anybody wants to drive this forward, we should enumerate the tools & 
associated pros/cons.

Dinesh

> On Feb 4, 2022, at 4:44 AM, Mick Semb Wever  wrote:
> 
> 
> 
> I think that it is not only about the build tool as such. There is a
> lot of scripting involved in build scripts as well as in Jenkins
> pipeline and so on. 
> 
> 
> Seconding this. Rewriting the build system is the easy bit. The ecosystem 
> (CI, releases, ccm, etc) is involved and not versioned (expects all branches 
> to work in the same way). Not impossible, or even challenging, but def 
> involved. 
> 

Re: [DISCUSS] Non Coding Committers

[Mick Semb Wever]

Thank you Sharan for sharing.


> So here in Apache Cassandra I see there is a whole lot of activity
> happening around the website, marketing, project promotion, blogs, social
> media - these activities are all contributions to the project. If there are
> contributions happening in the project that need a committer to action,
> then it could make sense to consider having committers that are focussed
> around the 'non coding' parts.
>
>
>

This is so true for us. We are spending a lot of extra time getting these
non-code contributions across the finish line. The context switching and
wait time involved in just one more handover, and often across time zones,
is hurting. And regardless, totally agree we should be formally recognising
the ongoing work that goes into these non-coding contributions.