Re: [DISCUSS] When to run CheckStyle and other verificiations

[Jacek Lewandowski]

So far, nobody referred to running checks in a pre-push (or pre-commit)
hook. The use of Git hooks is going to be introduced along with Accord, so
we could use them to force running checks once before sending changes to
the repo.
It would still be an opt-out approach because one would have to add the
"--no-verify" flag or uncheck a box in the commit dialog to skip running
the checks.

thanks,
Jacek


wt., 27 cze 2023 o 01:55 Ekaterina Dimitrova 
napisał(a):

> Thank you, Jacek, for starting the thread; those things are essential for
> developer productivity.
>
> I support the idea of opting out vs opting into checks. In my experience,
> it also makes things easier and faster during review time.
>
> If people have to opt-in - it is one more thing for new people to
> discover, and it will probably happen only during review time if they do
> not have access to Jenkins/paid CircleCI, etc.
>
> I also support consolidating all types of checks/analyses and running them
> together.
>
> Maxim’s suggestion about rat replacement sounds like a good improvement
> that can be explored (not part of what Jacek does here, though). Maxim, do
> you mind creating a ticket, please?
>
> Best regards,
> Ekaterina
>
> On Mon, 26 Jun 2023 at 17:04, Miklosovic, Stefan <
> stefan.mikloso...@netapp.com> wrote:
>
>> Yes, in this case, opting-out is better than opting-in. I feel like the
>> build process is quite versatile and one just picks what is necessary. I
>> never build docs, there is a flag for that. I turned off checkstyle because
>> I was fed up with that until Berenguer cached it and now I get ant jar with
>> checkstyle like under 10 seconds so I leave it on, which is great.
>>
>> Even though I feel like it is already flexible enough, grouping all
>> checkstyles and rats etc under one target seems like a good idea. From my
>> perspective, it is "all or nothing" so turning it all off until I am going
>> to push it so I want it all on is a good idea. I barely want to "just
>> checkstyle" in the middle of the development.
>>
>> I do not think that having a lot of flags is bad. I like that I have bash
>> aliases almost for everything and I bet folks have their tricks to get the
>> mundane stuff done.
>>
>> It would be pretty interesting to know the workflow of other people. I
>> think there would be a lot of insights how other people have it on a daily
>> basis when it comes to Cassandra development.
>>
>> 
>> From: David Capwell 
>> Sent: Monday, June 26, 2023 19:57
>> To: dev
>> Subject: Re: [DISCUSS] When to run CheckStyle and other verificiations
>>
>> NetApp Security WARNING: This is an external email. Do not click links or
>> open attachments unless you recognize the sender and know the content is
>> safe.
>>
>>
>>
>> not running it automatically with the targets which devs usually run
>> locally.
>>
>> The checks tend to have an opt-out, such as -Dno-checkstyle=true… so its
>> really easy to setup your local environment to opt out what you do not care
>> about… I feel we should force people to opt-out rather than opt-in…
>>
>>
>>
>> On Jun 26, 2023, at 7:47 AM, Jacek Lewandowski <
>> lewandowski.ja...@gmail.com> wrote:
>>
>> That would work as well Brandon, basically what is proposed in
>> CASSANDRA-18618, that is "check" target, actually needs to build the
>> project to perform some verifications - I suppose running "ant check"
>> should be sufficient.
>>
>> - - -- --- -  -
>> Jacek Lewandowski
>>
>>
>> pon., 26 cze 2023 o 16:01 Brandon Williams > dri...@gmail.com>> napisał(a):
>> The "artifacts" task is not quite the same since it builds other things
>> like docs, which significantly contributes to longer build time.  I don't
>> see why we couldn't add a new task that preserves the old behavior though,
>> "fulljar" or something like that.
>>
>> Kind Regards,
>> Brandon
>>
>>
>> On Mon, Jun 26, 2023 at 6:12 AM Jacek Lewandowski <
>> lewandowski.ja...@gmail.com> wrote:
>> Yes, I've mentioned that there is a property we can set to skip
>> checkstyle.
>>
>> Currently such a goal is "artifacts" which basically validates everything.
>>
>>
>> - - -- --- -  -
>> Jacek Lewandowski
>>
>>
>> pon., 26 cze 2023 o 13:09 Mike Adamson > madam...@datastax.com>> napisał(a):
>> While I like the idea of this because of added time these checks take, I
>> was under the impression that checkstyle (at least) can be disabled with a
>> flag.
>>
>> If we did do this, would it make sense to have a "release"  or "commit"
>> target (or some other name) that ran a full build with all checks that can
>> be used prior to pushing changes?
>>
>> On Mon, 26 Jun 2023 at 08:35, Berenguer Blasi > > wrote:
>>
>> I would prefer sthg that is totally transparent to me and not add one
>> more step I have to remember. Just to push/run CI to find out I missed it
>> and rinse and repeat... With the recent fix to

Re: [DISCUSS] When to run CheckStyle and other verificiations

[Miklosovic, Stefan]

I am doing all git-related operations in the console / bash (IDEA terminal, 
alt+f12 in IDEA). I know IDEA can do git stuff as well but I never tried it and 
I just do not care. I just do not "believe it" (yeah, call me old-fashioned if 
you want) so for me how it looks like in IDEA around some checkboxes I have to 
turn off is irrelevant.

I do not like the idea of git hooks. Maybe it is a matter of a strong habit but 
I am executing all these checks before I push anyway so for me the git hooks 
are not important and I would have to unlearn building it if git hook is going 
to do that for me instead.

If I am going to push 5 branches like this:

git push upstream cassandra-3.0 cassandra-3.11 cassandra-4.0 cassandra-4.1 
trunk --atomic

This means that git hooks would start to build 5 branches again? What if 
somebody pushes as I am building it? Building 5 branches from scratch would 
take like 10 minutes, probably ...


From: Jacek Lewandowski 
Sent: Tuesday, June 27, 2023 9:08
To: dev@cassandra.apache.org
Subject: Re: [DISCUSS] When to run CheckStyle and other verificiations

NetApp Security WARNING: This is an external email. Do not click links or open 
attachments unless you recognize the sender and know the content is safe.



So far, nobody referred to running checks in a pre-push (or pre-commit) hook. 
The use of Git hooks is going to be introduced along with Accord, so we could 
use them to force running checks once before sending changes to the repo.
It would still be an opt-out approach because one would have to add the 
"--no-verify" flag or uncheck a box in the commit dialog to skip running the 
checks.

thanks,
Jacek


wt., 27 cze 2023 o 01:55 Ekaterina Dimitrova 
mailto:e.dimitr...@gmail.com>> napisał(a):
Thank you, Jacek, for starting the thread; those things are essential for 
developer productivity.

I support the idea of opting out vs opting into checks. In my experience, it 
also makes things easier and faster during review time.

If people have to opt-in - it is one more thing for new people to discover, and 
it will probably happen only during review time if they do not have access to 
Jenkins/paid CircleCI, etc.

I also support consolidating all types of checks/analyses and running them 
together.

Maxim’s suggestion about rat replacement sounds like a good improvement that 
can be explored (not part of what Jacek does here, though). Maxim, do you mind 
creating a ticket, please?

Best regards,
Ekaterina

On Mon, 26 Jun 2023 at 17:04, Miklosovic, Stefan 
mailto:stefan.mikloso...@netapp.com>> wrote:
Yes, in this case, opting-out is better than opting-in. I feel like the build 
process is quite versatile and one just picks what is necessary. I never build 
docs, there is a flag for that. I turned off checkstyle because I was fed up 
with that until Berenguer cached it and now I get ant jar with checkstyle like 
under 10 seconds so I leave it on, which is great.

Even though I feel like it is already flexible enough, grouping all checkstyles 
and rats etc under one target seems like a good idea. From my perspective, it 
is "all or nothing" so turning it all off until I am going to push it so I want 
it all on is a good idea. I barely want to "just checkstyle" in the middle of 
the development.

I do not think that having a lot of flags is bad. I like that I have bash 
aliases almost for everything and I bet folks have their tricks to get the 
mundane stuff done.

It would be pretty interesting to know the workflow of other people. I think 
there would be a lot of insights how other people have it on a daily basis when 
it comes to Cassandra development.


From: David Capwell mailto:dcapw...@apple.com>>
Sent: Monday, June 26, 2023 19:57
To: dev
Subject: Re: [DISCUSS] When to run CheckStyle and other verificiations

NetApp Security WARNING: This is an external email. Do not click links or open 
attachments unless you recognize the sender and know the content is safe.



not running it automatically with the targets which devs usually run locally.

The checks tend to have an opt-out, such as -Dno-checkstyle=true… so its really 
easy to setup your local environment to opt out what you do not care about… I 
feel we should force people to opt-out rather than opt-in…



On Jun 26, 2023, at 7:47 AM, Jacek Lewandowski 
mailto:lewandowski.ja...@gmail.com>> wrote:

That would work as well Brandon, basically what is proposed in CASSANDRA-18618, 
that is "check" target, actually needs to build the project to perform some 
verifications - I suppose running "ant check" should be sufficient.

- - -- --- -  -
Jacek Lewandowski


pon., 26 cze 2023 o 16:01 Brandon Williams 
mailto:dri...@gmail.com>>>
 napisał(a):
The "artifacts" task is not quite the same since it builds other things like 
docs, which significantly contributes to longer build time.  I don'

Re: Writes after the column is dropped, broken reads, and TCM

[Marcus Eriksson]

Hi, reply inline below

On Mon, Jun 26, 2023 at 06:39:09PM +0200, Jakub Zytka wrote:
> Hello,
> 
> I want to discuss the possibilities of fixing CASSANDRA-18591 and
> CASSANDRA-18589 (~exceptions during reads), considering that TCM will
> become a reality soon.
> While both issues can be hit even on a single-node cluster, I think it's
> important for the solution to be at least TCM-friendly and easily
> extendable in the future.
>
...

> 
> Finally, let's consider the role of Transactional Cluster Metadata (TCM).
> With TCM, distinguishing and handling some of the aforementioned scenarios
> may become easier or even feasible. However, my familiarity with TCM
> internals and future plans is limited. Therefore, I would greatly
> appreciate any insights into the relationship between TCM and scenarios
> such as the ones I've described above.

With TCM a schema change bumps an epoch, this epoch is then serialized with
every read command/partition update and the replica can check if it is behind
or ahead of the coordinator. This allows the replica to either catch up with
the coordinator before executing the read/write or fail the request if the
coordinator is behind.

There are still a few races though, for example, the new schema is set on
the node before the new epoch is committed, so we might send a read/write
to a replica using the new schema but with the old epoch. Fixing this would
require us to rewrite the way we manage schemas and is currently out of
scope, but TCM would allow us to do so in the future.

/Marcus

Re: [DISCUSS] When to run CheckStyle and other verificiations

[Jacek Lewandowski]

Stefan, if you build using command line and then commit / push also in the
terminal, nothing would change for you:

now:
ant jar (automatically runs some checks)
git commit
git push

proposed:
ant jar (just build)
git commit (run some checks)
git push

Your point that pre-push hook might not be the best one is valid, and we
should rather think about pre-commit



- - -- --- -  -
Jacek Lewandowski


wt., 27 cze 2023 o 09:25 Miklosovic, Stefan 
napisał(a):

> I am doing all git-related operations in the console / bash (IDEA
> terminal, alt+f12 in IDEA). I know IDEA can do git stuff as well but I
> never tried it and I just do not care. I just do not "believe it" (yeah,
> call me old-fashioned if you want) so for me how it looks like in IDEA
> around some checkboxes I have to turn off is irrelevant.
>
> I do not like the idea of git hooks. Maybe it is a matter of a strong
> habit but I am executing all these checks before I push anyway so for me
> the git hooks are not important and I would have to unlearn building it if
> git hook is going to do that for me instead.
>
> If I am going to push 5 branches like this:
>
> git push upstream cassandra-3.0 cassandra-3.11 cassandra-4.0 cassandra-4.1
> trunk --atomic
>
> This means that git hooks would start to build 5 branches again? What if
> somebody pushes as I am building it? Building 5 branches from scratch would
> take like 10 minutes, probably ...
>
> 
> From: Jacek Lewandowski 
> Sent: Tuesday, June 27, 2023 9:08
> To: dev@cassandra.apache.org
> Subject: Re: [DISCUSS] When to run CheckStyle and other verificiations
>
> NetApp Security WARNING: This is an external email. Do not click links or
> open attachments unless you recognize the sender and know the content is
> safe.
>
>
>
> So far, nobody referred to running checks in a pre-push (or pre-commit)
> hook. The use of Git hooks is going to be introduced along with Accord, so
> we could use them to force running checks once before sending changes to
> the repo.
> It would still be an opt-out approach because one would have to add the
> "--no-verify" flag or uncheck a box in the commit dialog to skip running
> the checks.
>
> thanks,
> Jacek
>
>
> wt., 27 cze 2023 o 01:55 Ekaterina Dimitrova  > napisał(a):
> Thank you, Jacek, for starting the thread; those things are essential for
> developer productivity.
>
> I support the idea of opting out vs opting into checks. In my experience,
> it also makes things easier and faster during review time.
>
> If people have to opt-in - it is one more thing for new people to
> discover, and it will probably happen only during review time if they do
> not have access to Jenkins/paid CircleCI, etc.
>
> I also support consolidating all types of checks/analyses and running them
> together.
>
> Maxim’s suggestion about rat replacement sounds like a good improvement
> that can be explored (not part of what Jacek does here, though). Maxim, do
> you mind creating a ticket, please?
>
> Best regards,
> Ekaterina
>
> On Mon, 26 Jun 2023 at 17:04, Miklosovic, Stefan <
> stefan.mikloso...@netapp.com> wrote:
> Yes, in this case, opting-out is better than opting-in. I feel like the
> build process is quite versatile and one just picks what is necessary. I
> never build docs, there is a flag for that. I turned off checkstyle because
> I was fed up with that until Berenguer cached it and now I get ant jar with
> checkstyle like under 10 seconds so I leave it on, which is great.
>
> Even though I feel like it is already flexible enough, grouping all
> checkstyles and rats etc under one target seems like a good idea. From my
> perspective, it is "all or nothing" so turning it all off until I am going
> to push it so I want it all on is a good idea. I barely want to "just
> checkstyle" in the middle of the development.
>
> I do not think that having a lot of flags is bad. I like that I have bash
> aliases almost for everything and I bet folks have their tricks to get the
> mundane stuff done.
>
> It would be pretty interesting to know the workflow of other people. I
> think there would be a lot of insights how other people have it on a daily
> basis when it comes to Cassandra development.
>
> 
> From: David Capwell mailto:dcapw...@apple.com>>
> Sent: Monday, June 26, 2023 19:57
> To: dev
> Subject: Re: [DISCUSS] When to run CheckStyle and other verificiations
>
> NetApp Security WARNING: This is an external email. Do not click links or
> open attachments unless you recognize the sender and know the content is
> safe.
>
>
>
> not running it automatically with the targets which devs usually run
> locally.
>
> The checks tend to have an opt-out, such as -Dno-checkstyle=true… so its
> really easy to setup your local environment to opt out what you do not care
> about… I feel we should force people to opt-out rather than opt-in…

Re: Improved DeletionTime serialization to reduce disk size

[Mick Semb Wever]

>
> Just for completeness the change is a handful loc. The rest is added tests
> and we'd loose the sstable format change opportunity window.
>


+1, if you have time for this approach and no other in this window.

(If you have time for the other, or someone else does, then the technically
superior approach should win)

Re: [DISCUSS] When to run CheckStyle and other verificiations

[Mick Semb Wever]

> The context is that we currently have 3 checks in the build:
>
> - Checkstyle,
> - Eclipse-Warnings,
> - RAT


And dependency-check (owasp).



> I want to discuss whether you are ok with extracting all checks to their 
> distinct target and not running it automatically with the targets which devs 
> usually run locally. In particular:
>
>
> "build", "jar", and all "test" targets would not trigger CheckStyle, RAT or 
> Eclipse-Warnings
> A new target "check" would trigger all CheckStyle, RAT, and Eclipse-Warnings
> The new "check" target would be run along with the "artifacts" target on 
> Jenkins-CI, and it as a separate build step in CircleCI


+0 I prefer this opt-in over an opt-out approach.

It should be separated from `artifacts` too.
We would need to encourage engineers to run `ant check` before
starting CI and/or requesting review.

I'm in favour of the opt-in approach because it keeps it visible.
Folks configure flags and it "disappears" forever.  Also it's a
headache in all the other ant targets where we actually don't want it,
e.g. tests.

If we go with opt-out i'd like to see one flag that can disable all
checks: `-Dchecks.skip`


> That could be fixed by running checks in a pre-push Git hook. There are some 
> benefits of this compared to the current behavior:


-1
committing and pushing to a personal branch is often done to save work
or for cross-machine or collaboration. We should not gate on checks or
compilation here.

PRs should fail if checks fail, to give newcomers clear feedback (and
to take this nit-picking out of the review process).

[VOTE] CEP 33 - CIDR filtering authorizer

[Shailaja Koppu]

Hi Team,

Starting voting for this CEP 33 -  
https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-33%3A+CIDR+filtering+authorizer
 
.
 
Please vote for this CEP, I will merge the PR after review if passes the voting 
process.

(Changed the email subject to VOTE).

Thanks,
Shailaja



> On Jun 22, 2023, at 5:37 PM, Shailaja Koppu  wrote:
> 
> Hi Team,
> 
> If no one has comments/questions regarding this feature, I would like to 
> start voting thread on Monday.
> 
> 
> Thanks,
> Shailaja
> 
> 
>> On Jun 15, 2023, at 4:49 PM, Shailaja Koppu > > wrote:
>> 
>> Adding [DISCUSS] to the subject. I request everyone here to please share 
>> your thoughts/comments on this CEP.
>> 
>> Thank you @Nate.
>> 
>> 
>>> On Jun 15, 2023, at 12:48 AM, Nate McCall >> > wrote:
>>> 
>>> Hi Shailaja,
>>> This looks super interesting. I particularly like the MONITOR switch. This 
>>> is a huge pain-point for a lot of cluster migrations. 
>>> 
>>> Cheers,
>>> -Nate
>>> 
>>> On Thu, Jun 15, 2023 at 6:43 AM Shailaja Koppu >> > wrote:
>>> Hi Team,
>>> 
>>> I have created CEP 33 - CIDR filtering authorizer 
>>> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-33%3A+CIDR+filtering+authorizer
>>>  
>>> .
>>> 
>>> Purpose of this feature is to add the ability to restrict users accesses 
>>> based on the client’s IP (or region). We can map set of CIDRs to CIDR 
>>> groups (aka, regions), and then enable or disable roles to access from 
>>> certain CIDR groups. CEP page details why are we doing this and how. Please 
>>> go through it, comment here on the discussion thread and vote. 
>>> 
>>> For your reference, code for this feature is at 
>>> https://github.com/apache/cassandra/pull/2414 
>>> . PR description contains an 
>>> example usage.
>>> 
>>> 
>>> Thanks,
>>> Shailaja
>> 
> 

Re: [DISCUSS] When to run CheckStyle and other verificiations

[David Capwell]

> nobody referred to running checks in a pre-push (or pre-commit) hook


In accord I added an opt-out for each hook, and will require such here as well… 
as long as you can opt-out, its fine by me… I know I will likely opt-out, but 
wouldn’t block such an effort

> Your point that pre-push hook might not be the best one is valid, and we 
> should rather think about pre-commit

Pre-push is far better than pre-commit, with pre-commit you are forcing a style 
on people…. I for one have many many commits in a single PR, where I use 
commits to not loose track of progress (even if the code doesn’t compile), so 
forcing the build to work would be a -1 from me…. Pre-push at least means “you 
want the world to see this” so makes more sense there…

Again, must have an opt-out

> proposed:
> ant jar (just build)
> git commit (run some checks)

I am against this, jar should also check and ask users to opt-out if they don’t 
want the checks….

> If we go with opt-out i'd like to see one flag that can disable all checks: 
> `-Dchecks.skip`

Works for me, you can also do the following to disable and not worry about

$ cat < build.properties
checks.skip: true
EOF

> On Jun 27, 2023, at 3:14 AM, Mick Semb Wever  wrote:
> 
>> The context is that we currently have 3 checks in the build:
>> 
>> - Checkstyle,
>> - Eclipse-Warnings,
>> - RAT
> 
> 
> And dependency-check (owasp).
> 
> 
> 
>> I want to discuss whether you are ok with extracting all checks to their 
>> distinct target and not running it automatically with the targets which devs 
>> usually run locally. In particular:
>> 
>> 
>> "build", "jar", and all "test" targets would not trigger CheckStyle, RAT or 
>> Eclipse-Warnings
>> A new target "check" would trigger all CheckStyle, RAT, and Eclipse-Warnings
>> The new "check" target would be run along with the "artifacts" target on 
>> Jenkins-CI, and it as a separate build step in CircleCI
> 
> 
> +0 I prefer this opt-in over an opt-out approach.
> 
> It should be separated from `artifacts` too.
> We would need to encourage engineers to run `ant check` before
> starting CI and/or requesting review.
> 
> I'm in favour of the opt-in approach because it keeps it visible.
> Folks configure flags and it "disappears" forever.  Also it's a
> headache in all the other ant targets where we actually don't want it,
> e.g. tests.
> 
> If we go with opt-out i'd like to see one flag that can disable all
> checks: `-Dchecks.skip`
> 
> 
>> That could be fixed by running checks in a pre-push Git hook. There are some 
>> benefits of this compared to the current behavior:
> 
> 
> -1
> committing and pushing to a personal branch is often done to save work
> or for cross-machine or collaboration. We should not gate on checks or
> compilation here.
> 
> PRs should fail if checks fail, to give newcomers clear feedback (and
> to take this nit-picking out of the review process).

Re: [DISCUSS] When to run CheckStyle and other verificiations

[Jacek Lewandowski]

With git you can always opt-out by adding --no-verify flag to either push
or commit

I really prefer separate tasks than flags. Flags are not listed in the help
message like "ant -p" and are not auto-completed in the terminal. That
makes them almost undiscoverable for newcomers.

Want to have jar include checks? Ok, but let's don't run checks
automatically with "build" or "test"



wt., 27 cze 2023 o 18:26 David Capwell  napisał(a):

> nobody referred to running checks in a pre-push (or pre-commit) hook
>
>
>
> In accord I added an opt-out for each hook, and will require such here as
> well… as long as you can opt-out, its fine by me… I know I will likely
> opt-out, but wouldn’t block such an effort
>
> Your point that pre-push hook might not be the best one is valid, and we
> should rather think about pre-commit
>
>
> Pre-push is far better than pre-commit, with pre-commit you are forcing a
> style on people…. I for one have many many commits in a single PR, where I
> use commits to not loose track of progress (even if the code doesn’t
> compile), so forcing the build to work would be a -1 from me…. Pre-push at
> least means “you want the world to see this” so makes more sense there…
>
> Again, must have an opt-out
>
> proposed:
> ant jar (just build)
> git commit (run some checks)
>
>
> I am against this, jar should also check and ask users to opt-out if they
> don’t want the checks….
>
> If we go with opt-out i'd like to see one flag that can disable all checks:
> `-Dchecks.skip`
>
>
> Works for me, you can also do the following to disable and not worry about
>
> $ cat < build.properties
> checks.skip: true
> EOF
>
> On Jun 27, 2023, at 3:14 AM, Mick Semb Wever  wrote:
>
> The context is that we currently have 3 checks in the build:
>
> - Checkstyle,
> - Eclipse-Warnings,
> - RAT
>
>
>
> And dependency-check (owasp).
>
>
>
> I want to discuss whether you are ok with extracting all checks to their
> distinct target and not running it automatically with the targets which
> devs usually run locally. In particular:
>
>
> "build", "jar", and all "test" targets would not trigger CheckStyle, RAT
> or Eclipse-Warnings
> A new target "check" would trigger all CheckStyle, RAT, and
> Eclipse-Warnings
> The new "check" target would be run along with the "artifacts" target on
> Jenkins-CI, and it as a separate build step in CircleCI
>
>
>
> +0 I prefer this opt-in over an opt-out approach.
>
> It should be separated from `artifacts` too.
> We would need to encourage engineers to run `ant check` before
> starting CI and/or requesting review.
>
> I'm in favour of the opt-in approach because it keeps it visible.
> Folks configure flags and it "disappears" forever.  Also it's a
> headache in all the other ant targets where we actually don't want it,
> e.g. tests.
>
> If we go with opt-out i'd like to see one flag that can disable all
> checks: `-Dchecks.skip`
>
>
> That could be fixed by running checks in a pre-push Git hook. There are
> some benefits of this compared to the current behavior:
>
>
>
> -1
> committing and pushing to a personal branch is often done to save work
> or for cross-machine or collaboration. We should not gate on checks or
> compilation here.
>
> PRs should fail if checks fail, to give newcomers clear feedback (and
> to take this nit-picking out of the review process).
>
>
>

Re: Writes after the column is dropped, broken reads, and TCM

[Jakub Zytka]

>
>
> With TCM a schema change bumps an epoch, this epoch is then serialized with
> every read command/partition update and the replica can check if it is
> behind
> or ahead of the coordinator. This allows the replica to either catch up
> with
> the coordinator before executing the read/write or fail the request if the
> coordinator is behind.
>
OK. I understand that because the write's epoch is persisted this let's us
order writes wrt relevant column drop correctly on the basis of epoch (not
the timestamps like today - which doesn't work correctly).

-- 
Jakub Zytka
e. jakub.zy...@datastax.com
w. www.datastax.com

[VOTE] CEP 33 - CIDR filtering authorizer

[Shailaja Koppu]

Hi Team,

(Starting a new thread for VOTE instead of reusing the DISCUSS thread, to 
follow usual procedure).

Please vote on CEP 33 - CIDR filtering authorizer 
https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-33%3A+CIDR+filtering+authorizer
 
.

Thanks,
Shailaja

[DISCUSS] Maintain backwards compatibility after dependency upgrade in the 5.0

[Maxim Muzafarov]

Hello everyone,


We use the Dropwizard Metrics 3.1.5 library, which provides a basic
set of classes to easily expose Cassandra internals to a user through
various interfaces (the most common being JMX). We want to upgrade
this library version in the next major release 5.0 up to the latest
stable 4.2.19 for the following reasons:
- the 3.x (and 4.0.x) Dropwizard Metrics library is no longer
supported, which means that if we face a critical CVE, we'll still
need to upgrade, so it's better to do it sooner and more calmly;
- as of 4.2.5 the library supports jdk11, jdk17, so we will be in-sync
[1] as well as having some of the compatibility fixes mentioned in the
related JIRA [2];
- there have been a few user-related requests [3][4] whose
applications collide with the old version of the library, we want to
help them;


The problem

The problem with simply upgrading is that the JmxReporter class of the
library has moved from the com.codahale.metrics package in the 3.x
release to the com.codahale.metrics.jmx package in the 4.x release.
This is a problem for applications/tools that rely on the cassandra
classpath (lib/jars) as after the upgrade they may be looking for the
JmxReporter class which has changed its location.

A good example of the problem that we (or a user) may face after the
upgrade is our tests and the cassandra-driver-core 3.1.1, which uses
the old 3.x version of the library in tests. Of course, in this case,
we can upgrade the cassandra driver up to 4.x [5][6] to fix the
problem, as the new driver uses a newer version of the library, but
that's another story I won't go into for now. I'm talking more about
visualising the problem a user might face after upgrading to 5.0 if
he/she rely on the cassandra classpath, but on the other hand, they
might not face this problem at all because, as I understand, they will
provide this library in their applications by themselves.


So, since Cassandra has a huge ecosystem and a variety of tools that I
can't even imagine, the main question here is:

Can we move forward with this change without breaking backwards
compatibility with any kind of tools that we have considering the
example above as the main case? Do you have any thoughts on this?

The changes are here:
https://github.com/apache/cassandra/pull/2238/files



[1] 
https://github.com/dropwizard/metrics/pull/2180/files#diff-5dbf1a803ecc13ff945a08ed3eb09149a83615e83f15320550af8e3a91976446R14
[2] https://issues.apache.org/jira/browse/CASSANDRA-14667
[3] https://github.com/dropwizard/metrics/issues/1581#issuecomment-628430870
[4] https://issues.apache.org/jira/browse/STORM-3204
[5] https://issues.apache.org/jira/browse/CASSANDRA-15750
[6] https://issues.apache.org/jira/browse/CASSANDRA-17231

Re: [VOTE] CEP 33 - CIDR filtering authorizer

[Josh McKenzie]

+1

On Tue, Jun 27, 2023, at 1:17 PM, Shailaja Koppu wrote:
> Hi Team,
> 
> (Starting a new thread for VOTE instead of reusing the DISCUSS thread, to 
> follow usual procedure).
> 
> Please vote on CEP 33 - CIDR filtering authorizer 
> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-33%3A+CIDR+filtering+authorizer
>  
> .
> 
> Thanks,
> Shailaja

Re: [VOTE] CEP 33 - CIDR filtering authorizer

[Dinesh Joshi]

+1On Jun 27, 2023, at 1:23 PM, Josh McKenzie  wrote:+1On Tue, Jun 27, 2023, at 1:17 PM, Shailaja Koppu wrote:Hi Team,(Starting a new thread for VOTE instead of reusing the DISCUSS thread, to follow usual procedure).Please vote on CEP 33 - CIDR filtering authorizer https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-33%3A+CIDR+filtering+authorizer.Thanks,Shailaja

Re: [VOTE] CEP 33 - CIDR filtering authorizer

[Yifan Cai]

+1

On Tue, Jun 27, 2023 at 1:50 PM Dinesh Joshi  wrote:

> +1
>
>
> On Jun 27, 2023, at 1:23 PM, Josh McKenzie  wrote:
>
> 
> +1
>
> On Tue, Jun 27, 2023, at 1:17 PM, Shailaja Koppu wrote:
>
> Hi Team,
>
> (Starting a new thread for VOTE instead of reusing the DISCUSS thread, to
> follow usual procedure).
>
> Please vote on CEP 33 - CIDR filtering authorizer
>
> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-33%3A+CIDR+filtering+authorizer
> 
> .
>
> Thanks,
> Shailaja
>
>
>

Re: [VOTE] CEP 33 - CIDR filtering authorizer

[Francisco Guerrero]

+1 (nb)

On 2023/06/28 00:46:25 Yifan Cai wrote:
> +1
> 
> On Tue, Jun 27, 2023 at 1:50 PM Dinesh Joshi  wrote:
> 
> > +1
> >
> >
> > On Jun 27, 2023, at 1:23 PM, Josh McKenzie  wrote:
> >
> > 
> > +1
> >
> > On Tue, Jun 27, 2023, at 1:17 PM, Shailaja Koppu wrote:
> >
> > Hi Team,
> >
> > (Starting a new thread for VOTE instead of reusing the DISCUSS thread, to
> > follow usual procedure).
> >
> > Please vote on CEP 33 - CIDR filtering authorizer
> >
> > https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-33%3A+CIDR+filtering+authorizer
> > 
> > .
> >
> > Thanks,
> > Shailaja
> >
> >
> >
>