Re: [Discuss] disabling io.netty.transport.noNative in tests

[Jon Meredith]

I think the Native dependencies were disabled for in-jvm Netty because they
prevented the in-jvm dtest InstanceClassLoaders from being garbage
collected and were a source of out-of-metaspace exceptions.  I'll echo
Alex's comment that you will also need to investigate in-jvm upgrade tests.
I'm not sure if it's possible to load two different versions of native
libraries concurrently.

Perhaps the netty code has changed and we can re-enable, or perhaps you can
determine what was not being released by the native code -- that would be
much better and as Alex says more reflective of the common environment.

To check if it is now safe, you can use the ResourceLeakTest - you may have
to comment out a few @Ignores - the previous bar was for the
looperGossiperNetwork test to complete 100 loops.

Jon.

On Wed, Sep 6, 2023 at 9:32 AM Alex Petrov  wrote:

> I think most of the time people actually use netty _with_ native. This
> might have been introduced when we were tried to make shaded in-JVM dtest
> jars. If all tests are passing, and we actually do have a confirmtion that
> native Netty is being used, I would say +1 to remove `noNative`.
>
> Just to make sure though, did you have a chance to see if the upgrade
> tests also work fine?
>
> On Thu, Aug 31, 2023, at 1:20 PM, Miklosovic, Stefan wrote:
>
> Hi list,
>
> Currently, we are skipping the usage of native libraries in Netty as part
> of testing here (1).
>
> In 5.0 branch, we upgraded Netty to 4.1.96 and we brought all native
> dependencies to the class path so they are there in runtime (x86, arm, mac).
>
> I conducted few CI tests for 5.0+ and not having
> "io.netty.transport.noNative" set to "true" introduces no errors. I think
> we were just too motivated here to skip stuff left and right. Having this
> property enabled seems to have no functional effect. Also, one negative
> side-effect of having this property enabled is that it logs exceptions when
> running in-jvm-dtests e.g. in IDEA and it pollutes the logs unnecessarily
> and it is just a visual clutter to deal with every time. To silence this, I
> set (2) so it skips the logic in (3) completely hence no un-necessary
> logging will occure.
>
> My question is whether we should not remove (4) in 5.0, that means that
> tests will use native libraries too. That also means that we are running
> tests closer to a production environment. I just do not see any reason why
> we should skip this when all tests are just passing with it too with
> additional benefit of not seeing an exception logged every time when
> testing it locally.
>
> Thanks
>
> (1)
> https://github.com/apache/cassandra-in-jvm-dtest-api/blob/trunk/src/main/java/org/apache/cassandra/distributed/api/ICluster.java#L95-L102
> (2)
> https://github.com/apache/cassandra/blob/trunk/test/distributed/org/apache/cassandra/distributed/impl/AbstractCluster.java#L196
> (3)
> https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/service/NativeTransportService.java#L163
> (4)
> https://github.com/apache/cassandra-in-jvm-dtest-api/blob/trunk/src/main/java/org/apache/cassandra/distributed/api/ICluster.java#L101
>
>
>

Re: [VOTE] CEP-34: mTLS based client and internode authenticators

[Jon Meredith]

+1

On Fri, Jul 21, 2023 at 2:33 PM Blake Eggleston 
wrote:

> +1
>
> On Jul 21, 2023, at 9:57 AM, Jyothsna Konisa 
> wrote:
>
> Hi Everyone!
>
> I would like to start a vote thread for CEP-34.
>
> Proposal:
> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-34%3A+mTLS+based+client+and+internode+authenticators
> JIRA   :
> https://issues.apache.org/jira/browse/CASSANDRA-18554
> Draft Implementation : https://github.com/apache/cassandra/pull/2372
> Discussion :
> https://lists.apache.org/thread/pnfg65r76rbbs70hwhsz94ds6yo2042f
>
> The vote will be open for 72 hours. A vote passes if there are at least 3
> binding +1s and no binding vetoes.
>
> Thanks,
> Jyothsna Konisa.
>
>
>

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

[Jon Meredith]

+1 from me too. I would support removing all of the optional checks from
jar/test as I also hit issues with rat from time to time while iterating,
as long as the CI system runs them and makes it very clear for any
committer there are failures.

On Mon, Jul 10, 2023 at 9:40 AM Josh McKenzie  wrote:

>
>- Remove the checkstyle dependency from "jar" and "test"
>- Create a single "check" target that includes all the checks we
>expect to pass in the CI (currently Checkstyle, RAT, and Eclipse-Warnings),
>making this task the default.
>
> +1 here.
>
> (of note: haven't forgotten the request from this thread to share local
> env; just gotten sidetracked by things and also realized how little I've
> actually modified locally since I just run most of the linting against
> delta'ed files only to keep my changed work in compliance. Still a very
> noisy mess when SpotBugs is run against the entire codebase proper)
>
> On Mon, Jul 10, 2023, at 7:13 AM, Brandon Williams wrote:
>
> On Mon, Jul 10, 2023 at 6:07 AM Jacek Lewandowski
>  wrote:
> > Remove the checkstyle dependency from "jar" and "test"
> > Create a single "check" target that includes all the checks we expect to
> pass in the CI (currently Checkstyle, RAT, and Eclipse-Warnings), making
> this task the default.
>
> I support this.  Having checkstyle run when building is clearly
> constant friction for many, even though you can disable it.
>
>
>

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

[Jon Meredith]

sorry, hit send early.

ant test is an interesting one as it seems impractical to run all tests
sequentially, but somebody may want to I suppose.

On Thu, Jul 6, 2023 at 11:53 AM Jon Meredith  wrote:

> I think the -Dno-blah settings have usability issues. As they look at
> the property name, not the value, you cannot override them or default
> them with ANT_ARGS or by importing to another ant build file.  The way
> rat.skip does it seems much better using configured value.
>
> Ideally, I would like an easy/fast configuration to set a default for
> checks that slow up the compilation/test cycle locally to be able to
> iterate quickly compile and deal with javadoc/checkstyle comments when
> they're ready to commit, or opt into them on the commandline when
> needed.
>
> e.g.
> export ANT_ARGS="-Dcheckstyle.default=skip -Djavadoc.default=skip"
> ant # should just compile, no checkstyle/javadoc etc
> ant checkstyle  # explicitly requested, run checkstyle
>
> Similarly I'd like to have the option to configure any CI system I run so
> all
> non-execution essential checks run in their own pipeline and fail the
> build if there's a problem, but still run the other test targets despite
> violations. Each builder wasted the time running the checks that only
> need to happen once and you didn't get feedback about your tests that
> could have run. Of course not everybody may want that and the main
> Apache Cassandra CI may only want to run tests for checked commits
> for resource reasons.
>
> Also,as a minor nuisance, if you forget the =true as in the examples,
> ant consumes the next argument as the value, so "ant publish
> -Dno-tests -Dno-checks" would set no-tests=-Dno-checks and run the
> checks you tried to skip anyway.
>
> Back to the proposal, I like the idea of an explicit check target that
> runs all checks,
> I would not personally have the default target run them but think that's
> fine as long
> as you can disable them.
>
> ant test is an interesting one
>
> On Thu, Jul 6, 2023 at 7:30 AM Maxim Muzafarov  wrote:
>
>> In my humble opinion, it is better to have only one plain and
>> straightforward build pipeline for the whole project, with custom
>> flags used to skip a particular step, than to have multiple pipelines
>> under the ant tool with multiple endpoints accordingly. I mean, all
>> the steps need to be lined up, with each step in the pipeline
>> executing everything that stands before it unless skip flags are
>> specified. Meanwhile, I like your idea of grouping all the checks
>> under the dedicated step (and changing the no-checkstyle flag to
>> no-checks accordingly as Ekaterina mentioned).
>>
>>
>> Let me share a simple example of what I'm talking about with one
>> single endpoint.
>> Let's assume the following step order:
>>
>> init -> _build_java (compile) -> checks -> build -> jar -> test ->
>> artifacts -> publish;
>>
>> So, the use would be:
>>
>> ant jar -Dno-checks
>> ant test -Dno-build
>> ant publish -Dno-tests -Dno-checks
>>
>>
>> I'm not saying what you've proposed is bad, in fact, we're not
>> currently doing the pipeline I'm talking about, but adding an
>> additional endpoint is something we should consider very carefully as
>> it may create some difficulties for Maven/Gradle migration if it ever
>> happens.
>>
>> So, if I'm not mistaken the following you're trying to add a new
>> endpoint to the way how we might build the project:
>>
>> - "ant [check]" = build + all checks (first endpoint)
>> - "ant jar" = build + make jars + no checks (second endpoint)
>>
>> And I would suggest running `ant jar -Dno-checks` instead to achieve
>> the same result assuming the `jar` is still transitively dependent on
>> `checks`.
>>
>> On Thu, 6 Jul 2023 at 14:02, Jacek Lewandowski
>>  wrote:
>> >
>> > Great discussion, but I feel we still have no conclusion.
>> >
>> >
>> > I fully support automatically setting up IDE(A) to run the necessary
>> stuff automatically in a developer-friendly environment, but let it be
>> continued in a separate thread.
>> >
>> >
>> > I wouldn't say I like flags, especially if they have to be used on a
>> daily basis. The build script help message does not list them when "ant -p"
>> is run.
>> >
>> >
>> > I'm going to make these changes unless it is vetoed:
>> >
>> > "ant [check]" = build + all checks, build everything, and run all the
>> checks; also, this wo

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

[Jon Meredith]

I think the -Dno-blah settings have usability issues. As they look at
the property name, not the value, you cannot override them or default
them with ANT_ARGS or by importing to another ant build file.  The way
rat.skip does it seems much better using configured value.

Ideally, I would like an easy/fast configuration to set a default for
checks that slow up the compilation/test cycle locally to be able to
iterate quickly compile and deal with javadoc/checkstyle comments when
they're ready to commit, or opt into them on the commandline when
needed.

e.g.
export ANT_ARGS="-Dcheckstyle.default=skip -Djavadoc.default=skip"
ant # should just compile, no checkstyle/javadoc etc
ant checkstyle  # explicitly requested, run checkstyle

Similarly I'd like to have the option to configure any CI system I run so
all
non-execution essential checks run in their own pipeline and fail the
build if there's a problem, but still run the other test targets despite
violations. Each builder wasted the time running the checks that only
need to happen once and you didn't get feedback about your tests that
could have run. Of course not everybody may want that and the main
Apache Cassandra CI may only want to run tests for checked commits
for resource reasons.

Also,as a minor nuisance, if you forget the =true as in the examples,
ant consumes the next argument as the value, so "ant publish
-Dno-tests -Dno-checks" would set no-tests=-Dno-checks and run the
checks you tried to skip anyway.

Back to the proposal, I like the idea of an explicit check target that runs
all checks,
I would not personally have the default target run them but think that's
fine as long
as you can disable them.

ant test is an interesting one

On Thu, Jul 6, 2023 at 7:30 AM Maxim Muzafarov  wrote:

> In my humble opinion, it is better to have only one plain and
> straightforward build pipeline for the whole project, with custom
> flags used to skip a particular step, than to have multiple pipelines
> under the ant tool with multiple endpoints accordingly. I mean, all
> the steps need to be lined up, with each step in the pipeline
> executing everything that stands before it unless skip flags are
> specified. Meanwhile, I like your idea of grouping all the checks
> under the dedicated step (and changing the no-checkstyle flag to
> no-checks accordingly as Ekaterina mentioned).
>
>
> Let me share a simple example of what I'm talking about with one
> single endpoint.
> Let's assume the following step order:
>
> init -> _build_java (compile) -> checks -> build -> jar -> test ->
> artifacts -> publish;
>
> So, the use would be:
>
> ant jar -Dno-checks
> ant test -Dno-build
> ant publish -Dno-tests -Dno-checks
>
>
> I'm not saying what you've proposed is bad, in fact, we're not
> currently doing the pipeline I'm talking about, but adding an
> additional endpoint is something we should consider very carefully as
> it may create some difficulties for Maven/Gradle migration if it ever
> happens.
>
> So, if I'm not mistaken the following you're trying to add a new
> endpoint to the way how we might build the project:
>
> - "ant [check]" = build + all checks (first endpoint)
> - "ant jar" = build + make jars + no checks (second endpoint)
>
> And I would suggest running `ant jar -Dno-checks` instead to achieve
> the same result assuming the `jar` is still transitively dependent on
> `checks`.
>
> On Thu, 6 Jul 2023 at 14:02, Jacek Lewandowski
>  wrote:
> >
> > Great discussion, but I feel we still have no conclusion.
> >
> >
> > I fully support automatically setting up IDE(A) to run the necessary
> stuff automatically in a developer-friendly environment, but let it be
> continued in a separate thread.
> >
> >
> > I wouldn't say I like flags, especially if they have to be used on a
> daily basis. The build script help message does not list them when "ant -p"
> is run.
> >
> >
> > I'm going to make these changes unless it is vetoed:
> >
> > "ant [check]" = build + all checks, build everything, and run all the
> checks; also, this would become the default target if no target is specified
> > "ant jar" = build + make jars: build all the jars and tests, no checks
> > All "test" commands = build + make jars + run the tests: build all the
> jars and tests, run the tests, no checks
> >
> >
> > Therefore, a user who wants to validate their branch before running CI
> would need to run just "ant" without any args. This way, a newcomer who
> does not know our build targets will likely run the checks.
> >
> >
> > We still need some flags for skipping specific tasks to optimize for CI,
> but in general, they would not be required for local development.
> >
> >
> > Flags will also be needed to customize some tasks, but they should be
> optional for newcomers. In addition, a "help" target could display a list
> of selected tasks and properties with descriptions.
> >
> >
> > I'd be more than happy if we could conclude the discussion somehow and
> move forward :)
> >
> >
> > 

Re: [VOTE] Release dtest-api 0.0.15

[Jon Meredith]

+1

On Wed, May 24, 2023 at 10:13 AM Francisco Guerrero 
wrote:

> +1 (nb)
>
> On 2023/05/24 15:38:54 Alex Petrov wrote:
> > +1
> >
> > On Wed, May 24, 2023, at 5:36 PM, Doug Rohrer wrote:
> > > +1 (nb)
> > >
> > > > On May 24, 2023, at 11:32 AM, Brandon Williams 
> wrote:
> > > >
> > > > +1
> > > >
> > > > Kind Regards,
> > > > Brandon
> > > >
> > > > On Wed, May 24, 2023 at 10:31 AM Dinesh Joshi 
> wrote:
> > > >>
> > > >> Proposing the test build of in-jvm dtest API 0.0.15 for release.
> > > >>
> > > >> Repository:
> > > >>
> https://gitbox.apache.org/repos/asf?p=cassandra-in-jvm-dtest-api.git
> > > >>
> > > >> Candidate SHA:
> > > >>
> https://github.com/apache/cassandra-in-jvm-dtest-api/commit/48af78d1d4b5f285d3dd4991afd4df3101e3983a
> > > >> tagged with 0.0.15
> > > >>
> > > >> Artifacts:
> > > >>
> https://repository.apache.org/content/repositories/orgapachecassandra-1290/org/apache/cassandra/dtest-api/0.0.15/
> > > >>
> > > >> Key signature: 53371F9B1B425A336988B6A03B6042413D323470
> > > >>
> > > >> Changes since last release:
> > > >>
> > > >> * CASSANDRA-18537: Add JMX utility class to in-jvm dtest to ease
> > > >> development of new tests using JMX
> > > >>
> > > >> The vote will be open for 24 hours. 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.
> > >
> > >
>

Re: [VOTE] Release dtest-api 0.0.14

[Jon Meredith]

+1

On Tue, May 16, 2023 at 3:39 AM Andrés de la Peña 
wrote:

> +1
>
> On Tue, 16 May 2023 at 07:24, Alex Petrov  wrote:
>
>> +1
>>
>> On Tue, May 16, 2023, at 4:45 AM, Doug Rohrer wrote:
>>
>> +1 (nb)
>>
>> Doug Rohrer
>>
>> > On May 15, 2023, at 7:17 PM, Brandon Williams  wrote:
>> >
>> > +1
>> >
>> > Kind Regards,
>> > Brandon
>> >
>> >> On Mon, May 15, 2023 at 5:12 PM Dinesh Joshi 
>> wrote:
>> >>
>> >> Proposing the test build of in-jvm dtest API 0.0.14 for release.
>> >>
>> >> Repository:
>> >> https://gitbox.apache.org/repos/asf?p=cassandra-in-jvm-dtest-api.git
>> >>
>> >> Candidate SHA:
>> >>
>> https://github.com/apache/cassandra-in-jvm-dtest-api/commit/ea4b44e0ed0a4f0bbe9b18fb40ad927b49a73a32
>> >> tagged with 0.0.14
>> >>
>> >> Artifacts:
>> >>
>> https://repository.apache.org/content/repositories/orgapachecassandra-1289/org/apache/cassandra/dtest-api/0.0.14/
>> >>
>> >> Key signature: 53371F9B1B425A336988B6A03B6042413D323470
>> >>
>> >> Changes since last release:
>> >>
>> >> * CASSANDRA-18511: Add support for JMX in jvm-dtest
>> >>
>> >> The vote will be open for 24 hours. 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.
>>
>>

Re: [VOTE] Release Apache Cassandra 4.1.0 (take2)

[Jon Meredith]

Thanks for the extra time to investigate. Unfortunately no progress on
finding the root cause for this issue, just successful bootstraps in our
attempts to reproduce. I think highlighting the ticket in the release notes
is sufficient and resolving this issue should not hold up the release.

I agree with Jeff that the multiple concurrent bootstraps are unlikely to
be the issue - I only mentioned in the ticket in case I am wrong. Abe or I
will update the ticket if we find anything new.

On Sun, Dec 11, 2022 at 12:33 PM Jeff Jirsa  wrote:

> Concurrent shouldn’t matter (they’re non-overlapping in the repro). And
> I’d personally be a bit surprised if table count matters that much.
>
> It probably just requires high core count and enough data that the streams
> actually interact with the rate limiter
>
> On Dec 11, 2022, at 10:32 AM, Mick Semb Wever  wrote:
>
> 
>
>
> On Sat, 10 Dec 2022 at 23:09, Abe Ratnofsky  wrote:
>
>> Sorry - responded on the take1 thread:
>>
>> Could we defer the close of this vote til Monday, December 12th after 6pm
>> Pacific Time?
>>
>> Jon Meredith and I have been working thru an issue blocking streaming on
>> 4.1 for the last couple months, and are now testing a promising fix. We're
>> currently working on a write-up, and we'd like to hold the release until
>> the community is able to review our findings.
>>
>
>
> Update on behalf of Jon and Abe.
>
> The issue raised is CASSANDRA-18110.
> Concurrent, or nodes with high cpu count and number of tables performing,
> host replacements can fail.
>
> It is still unclear if this is applicable to OSS C*, and if so to what
> extent users might ever be impacted.
> More importantly, there's a simple workaround for anyone that hits the
> problem.
>
> Without further information on the table, I'm inclined to continue with
> 4.1.0 GA (closing the vote in 32 hours), but add a clear message to the
> release announcement of the issue and workaround. Interested in hearing
> others' positions, don't be afraid to veto if that's where you're at.
>
>
>

Re: CEP-15 multi key transaction syntax

[Jon Meredith]

The reason I brought up static columns was for cases where multiple
statements update them and there could be ambiguity.

CREATE TABLE tbl
{
  pk1 int,
  ck2 int,
  s3 static int,
  r4 static int,
  PRIMARY KEY (pk1, ck2)
}

BEGIN TRANSACTION
UPDATE tbl SET s3=1, r4=1 WHERE pk1=1 AND ck2=1;
UPDATE tbl SET s3=2, r4=2 WHERE pk1=1 AND ck2=2;
COMMIT TRANSACTION

What should the final value be for s3?

This makes me realize I don't understand how upsert statements that touch
the same row would be applied in general within a transaction.
If the plan is for only-once-per-row within a transaction, then I think
regular columns and static columns should be split into their own UPSERT
statements.

On Thu, Jun 16, 2022 at 10:40 AM Benedict Elliott Smith 
wrote:

> I like Postgres' approach of letting you declare an exceptional condition
> and failing if there is not precisely one result (though I would prefer to
> differentiate between 0 row->Null and 2 rows->first row), but once you
> permit coercing to NULL I think you have to then treat it like NULL and
> permit arithmetic (that itself yields NULL)
>
> This is explicitly stipulated in ANSI SQL 92, in 6.12  expression>:
>
> General Rules
>
>  1) If the value of any  simply contained in a
>  is the null value, then the result
> of
> the  is the null value.
>
>
> On 2022/06/16 16:02:33 Blake Eggleston wrote:
> > Yeah I'd say NULL is fine for condition evaluation. Reference assignment
> is a little trickier. Assigning null to a column seems ok, but we should
> raise an exception if they're doing math or something that expects a
> non-null value
> >
> > > On Jun 16, 2022, at 8:46 AM, Benedict Elliott Smith <
> bened...@apache.org> wrote:
> > >
> > > AFAICT that standard addresses server-side cursors, not the assignment
> of a query result to a variable. Could you point to where it addresses
> variable assignment?
> > >
> > > Postgres has a similar concept, SELECT INTO[1], and it explicitly
> returns NULL if there are no result rows, unless STRICT is specified in
> which case an error is returned. My recollection is that T-SQL is also fine
> with coercing no results to NULL when assigning to a variable or using it
> in a sub-expression.
> > >
> > > I'm in favour of expanding our functionality here, but I do not see
> anything fundamentally problematic about the proposal as it stands.
> > >
> > > [1]
> https://www.postgresql.org/docs/current/plpgsql-statements.html#PLPGSQL-STATEMENTS-SQL-ONEROW
> > >
> > >
> > >
> > > On 2022/06/13 14:52:41 Konstantin Osipov wrote:
> > >> * bened...@apache.org  [22/06/13 17:37]:
> > >>> I believe that is a MySQL specific concept. This is one problem with
> mimicking SQL – it’s not one thing!
> > >>>
> > >>> In T-SQL, a Boolean expression is TRUE, FALSE or UNKNOWN[1], and a
> NULL value submitted to a Boolean operator yields UNKNOWN.
> > >>>
> > >>> IF (X) THEN Y does not run Y if X is UNKNOWN;
> > >>> IF (X) THEN Y ELSE Z does run Z if X is UNKNOWN.
> > >>>
> > >>> So, I think we have evidence that it is fine to interpret NULL
> > >>> as “false” for the evaluation of IF conditions.
> > >>
> > >> NOT FOUND handler is in ISO/IEC 9075-4:2003 13.2 
> > >>
> > >> In Cassandra results, there is no way to distinguish null values
> > >> from absence of a row. Branching, thus, without being able to
> > >> branch based on the absence of a row, whatever specific syntax
> > >> is used for such branching, is incomplete.
> > >>
> > >> More broadly, SQL/PSM has exception and condition statements, not
> > >> just IF statements.
> > >>
> > >> --
> > >> Konstantin Osipov, Moscow, Russia
> > >>
> >
> >
>

Re: [DISCUSSION] Shall we update Constants.KEY_DTEST_API_CONFIG_CHECK to true by default for in-jvm upgrade tests?

[Jon Meredith]

I think checking the validation rules as part of testing is important, but
making that a per-test concern for handling it may be frustrating.

What do you think about extending in-JVM with a method that provides the
previous config and version and expects the Instance implementation to
upgrade it, and then leave the validation on? That would provide some
documentation of how deprecated/removed options are expected to be migrated.

It might also be worthwhile extending the upgrade tests so that we can also
specify new configuration in addition to migrated configurated as the
instance is upgraded.

On Mon, Apr 4, 2022 at 8:43 AM Ekaterina Dimitrova 
wrote:

> Hi everyone,
> In In-jvm tests there is a flag Constants.KEY_DTEST_API_CONFIG_CHECK to
> opt-in/out from config checks done in YamlConfigurationLoader#check().
> The upgrade tests are currently set to ignore that check in order to work
> around dealing with new properties in newer versions. What does this mean?
> My understanding is that the lowest version from which we start an upgrade
> test will load Config and use it for all versions. This means that our
> checks will fail because in newer versions we set new config in
> InstanceConfig that doesn't exist in the old version Config. If we opt in,
> the tests will start failing because we need to remove parameters.
>
> I suggest we opt in by default to the checks so people consciously add
> their config. What do I mean? Currently with the new types and names in
> trunk, we exercise the backward compatibility and we set the old config
> names and values that work with the previous versions and exercise the
> backward compatibility but If I add a new name to set for config, this will
> just be ignored silently and default Config is used. Test might even
> pass...This is risky.
> This was documented but I think the right course of action is to opt in
> for checks and people ignore the checks in upgrade tests when they are sure
> they add the right config and no typos, etc and they understand the
> implications. The situation since that check was added has changed and if
> we keep on adding more tests, I think this is important so we are sure we
> test properly.
>
> Please let me know if I am wrong in my understanding and what you think.
>
> Best regards,
> Ekaterina
>

Re: [DISCUSS] CASSANDRA-17024: Artificial Latency Injection

[Jon Meredith]

Wouldn't modifying the CQL grammar would require updating the
application under test to perform experimentation?
The other thing I was wondering about is extensibility - for example
you would like to add a percentage chance for dropping messages for
more deterministic overload modeling.

I can see it being a property you set on keyspaces and/or tables as
that wouldn't be as intrusive or possible to execute with an ALTER
statement. Perhaps you could extend the ALTER TABLE/KEYSPACE grammar
to allow supplying a JSON blob that contains simulation / testing
parameters and have a setting in Config that enables the use of them
(default disabled) to prevent production issues.

yaml:
allow_simulation: true

cql:
ALTER TABLE keyspace.table WITH simulation = '{ "drop_percentage":
0.01, "additional_latency_millis": { "DC1": 1, "DC2": 80, "DC3": 200 }
}';

On Fri, Nov 19, 2021 at 9:00 AM Jeremiah D Jordan
 wrote:
>
> If it is per query, then I would think protocol level might be easier to 
> “test” a given application with.  Rather than having to append "WITH 
> ADDITIONAL LATENCY” to all your queries, you just set some option in your 
> query based object or such.  We already have support at the protocol level 
> for arbitrary query options being added, if you are worried about some driver 
> needing to add support it could be done through those.  Most of the drivers I 
> have looked at provide a method to put data into that metadata.
>
> I guess if you want to be the most flexible you could do both?  I could see 
> such a setting being done on multiple levels, implementing one or more of the 
> following:
>
> 1. As a new entry in the STARTUP message during connection handshake 
> introduced in a new native protocol version -> add latency to every response 
> over this connection
> 2. A new CQL command that sets the connection level latency -> all requests 
> after this command on this connection get additional latency XYZ (this 
> probably does still need some driver support, like USE as it would need the 
> driver to know to run the command on every open connection it had)
> 3. A new CQL command that sets the latency to a given ip/user -> all requests 
> after this command for a connection from the specified ip/user to the current 
> node get additional latency XYZ (this could help getting around multiple 
> connection issues, though unless it got propagated to all nodes in the 
> cluster you would still need some driver support to send the command to every 
> node the client was connected to)
> 4. As part of the request custom payload side channel -> just affects this 
> query
> 5. As part of a new flag introduced in a new native protocol version -> just 
> affects this query
> 6. As part of the CQL statements themselves -> just affects this query
>
> I can see good uses for most of those.  A CQL command to enable it globally 
> (2 or 3), and then additional CQL for per query (6) is probably supported by 
> the most existing clients without needing any changes.  I do think just 
> having a new per statement CQL option is not a great choice.  Though the 
> limitations of how 2/3 could be implemented make me think the “per request 
> custom payload” may actually be the option that is the most useful with the 
> least driver/user code change needed to work with it.
>
> -Jeremiah
>
> > On Nov 19, 2021, at 8:25 AM, bened...@apache.org wrote:
> >
> > To resurrect this discussion briefly, does anyone have a preference for 
> > either CQL Grammar or Protocol support?
> >
> > This originally felt to me like something we might want to support at the 
> > native protocol level, however that creates a dependency on specific 
> > clients and the feature might ultimately be less flexible. It’s not clear 
> > why we wouldn’t prefer some kind of CQL change like:
> >
> > SELECT * FROM table WHERE pk = x WITH ADDITIONAL LATENCY
> >
> > With queries being able to supply specific latencies if they so choose:
> >
> > SELECT * FROM table WHERE pk = x WITH ADDITIONAL LATENCY 4ms
> >
> > That might even support some DC->DC map for additional latencies:
> >
> > SELECT * FROM table WHERE pk = x WITH ADDITIONAL LATENCY ‘{dc1:{dc2: 4ms}}’
> >
> > This would leave applications a great deal of flexibility for experimenting 
> > with latency impacts, and greater ease for evolving this feature over time 
> > than specifying query eligibility at the protocol level.
> >
> > Does anyone have any thoughts about this?
> >
> > From: bened...@apache.org   > >
> > Date: Wednesday, 6 October 2021 at 14:48
> > To: dev@cassandra.apache.org  
> > mailto:dev@cassandra.apache.org>>
> > Subject: Re: [DISCUSS] CASSANDRA-17024: Artificial Latency Injection
> > This is a very good point. I forget the reason we settled on consistency 
> > levels, I assume it was due to simplicity of the solution, as deploying 
> > support for a new protocol-level change is more involved.
> >
> 

Re: [VOTE] CEP-15: General Purpose Transactions

[Jon Meredith]

+1 to all (nb)

I think this CEP is valuable because it improves on the existing
shortcomings in performance and ability to execute queries that can be
expressed in CQL statements and provides a foundation for future work.
Adding interactive transactions is not in the original scope of the
CEP, nor is a path to full SQL support and is unhelpful to couple
those things in a downvote.

This is only a vote that the community agrees to review changes that
support the CEP, and there is still community review to validate the
changes including other aspects like operability.

The engagement on this thread show there's an appetite for evolving
Cassandra which should be done through future CEPs and I do not
believe this work prevents that from happening.

Jon

On Fri, Oct 15, 2021 at 8:08 AM Michael Shuler  wrote:
>
> 1. +1
> 2. +1
> 3. +1
>
> On 10/14/21 11:31 AM, bened...@apache.org wrote:
> > Hi everyone,
> >
> > I would like to start a vote on this CEP, split into three sub-decisions, 
> > as discussion has been circular for some time.
> >
> > 1. Do you support adopting this CEP?
> > 2. Do you support the transaction semantics proposed by the CEP for 
> > Cassandra?
> > 3. Do you support an incremental approach to developing transactions in 
> > Cassandra, leaving scope for future development?
> >
> > The first vote is a consensus vote of all committers, the second and third 
> > however are about project direction and therefore are simple majority votes 
> > of the PMC.
> >
> > Recall that all -1 votes must be accompanied by an explanation. If you 
> > reject the CEP only on grounds (2) or (3) you should not veto the proposal. 
> > If a majority reject grounds (2) or (3) then transaction developments will 
> > halt for the time being.
> >
> > This vote will be open for 72 hours.
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: Welcome Jon Meredith as Cassandra committer

[Jon Meredith]

Thanks so much everybody, you make a person feel very welcome.

Patrick: I was hoping nobody noticed :)


On Fri, Jul 30, 2021 at 1:58 PM Patrick McFadin  wrote:

> Congratulations Jon and what great timing for the famous "Hold everything!"
> guy from the 4.0 release. :D
>
> https://www.theregister.com/2021/07/19/cassandra_40_delay/
>
>
> On Fri, Jul 30, 2021 at 9:57 AM Yifan Cai  wrote:
>
> > Congrats Jon!
> >
> > On Fri, Jul 30, 2021 at 8:48 AM Joshua McKenzie 
> > wrote:
> >
> > > Congratulations Jon!
> > >
> > >
> > > On Fri, Jul 30, 2021 at 10:35 AM Andrés de la Peña <
> > > a.penya.gar...@gmail.com>
> > > wrote:
> > >
> > > > Congratulations, Jon!
> > > >
> > > > On Fri, 30 Jul 2021 at 16:07, J. D. Jordan <
> jeremiah.jor...@gmail.com>
> > > > wrote:
> > > >
> > > > > Congrats Jon!
> > > > >
> > > > > > On Jul 30, 2021, at 9:26 AM, Paulo Motta <
> pauloricard...@gmail.com
> > >
> > > > > wrote:
> > > > > >
> > > > > > Congratulations and welcome Jon! Always exciting to see the
> > project
> > > > > > recognizing more committers!
> > > > > >
> > > > > >> Em sex., 30 de jul. de 2021 às 11:20, Benjamin Lerer <
> > > > b.le...@gmail.com
> > > > > >
> > > > > >> escreveu:
> > > > > >>
> > > > > >> Congratulations Jon. :-)
> > > > > >>
> > > > > >> Le ven. 30 juil. 2021 à 15:42, Ekaterina Dimitrova <
> > > > > e.dimitr...@gmail.com>
> > > > > >> a écrit :
> > > > > >>
> > > > > >>> Congrats!!! Well deserved!!!  
> > > > > >>>
> > > > > >>>> On Fri, 30 Jul 2021 at 9:32, Jonathan Ellis <
> jbel...@gmail.com>
> > > > > wrote:
> > > > > >>>
> > > > > >>>> Congratulations, Jon!
> > > > > >>>>
> > > > > >>>> On Fri, Jul 30, 2021 at 8:29 AM Brandon Williams <
> > > dri...@gmail.com>
> > > > > >>> wrote:
> > > > > >>>>
> > > > > >>>>> The Project Management Committee (PMC) for Apache Cassandra
> > > > > >>>>> has invited Jon Meredith to become a committer and we are
> > pleased
> > > > > >>>>> to announce that he has accepted.
> > > > > >>>>>
> > > > > >>>>> Thanks for all helping make Cassandra great!
> > > > > >>>>>
> > > > > >>>>> Congratulations,
> > > > > >>>>> The Apache Cassandra PMC members
> > > > > >>>>>
> > > > > >>>>>
> > > > -
> > > > > >>>>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > > > > >>>>> For additional commands, e-mail:
> dev-h...@cassandra.apache.org
> > > > > >>>>>
> > > > > >>>>>
> > > > > >>>>
> > > > > >>>> --
> > > > > >>>> Jonathan Ellis
> > > > > >>>> co-founder, http://www.datastax.com
> > > > > >>>> @spyced
> > > > > >>>>
> > > > > >>>
> > > > > >>
> > > > >
> > > > >
> -
> > > > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > > > > For additional commands, e-mail: dev-h...@cassandra.apache.org
> > > > >
> > > > >
> > > >
> > >
> >
>

Re: [VOTE] Release Apache Cassandra 4.0.0 (third time is the charm)

[Jon Meredith]

+1 (nb)

On Fri, Jul 23, 2021 at 10:22 AM Jake Luciani  wrote:

> +1
>
> On Fri, Jul 23, 2021 at 11:31 AM Blake Eggleston
>  wrote:
>
> > +1
> >
> > > On Jul 23, 2021, at 6:39 AM, Branimir Lambov <
> > branimir.lam...@datastax.com> wrote:
> > >
> > > +1
> > >
> > >> On Fri, Jul 23, 2021 at 4:15 PM Aleksey Yeschenko  >
> > >> wrote:
> > >>
> > >> +1
> > >>
> >  On 23 Jul 2021, at 14:03, Joshua McKenzie 
> > wrote:
> > >>>
> > >>> +1
> > >>>
> > >>> On Fri, Jul 23, 2021 at 8:07 AM Dinesh Joshi
> >  > >>>
> > >>> wrote:
> > >>>
> >  +1
> > 
> > 
> > > On Jul 23, 2021, at 4:56 AM, Paulo Motta  >
> >  wrote:
> > >
> > > +1
> > >
> > >> Em sex., 23 de jul. de 2021 às 08:37, Andrés de la Peña <
> > >> a.penya.gar...@gmail.com> escreveu:
> > >>
> > >> +1
> > >>
> > >>> On Fri, 23 Jul 2021 at 11:56, Sam Tunnicliffe 
> > >> wrote:
> > >>>
> > >>> +1
> > >>>
> >  On 22 Jul 2021, at 23:40, Brandon Williams <
> >  brandonwilli...@apache.org
> > >>>
> > >>> wrote:
> > 
> >  I am proposing the test build of Cassandra 4.0.0 for release.
> > 
> >  sha1: 902b4d31772eaa84f05ffdc1e4f4b7a66d5b17e6
> >  Git:
> > >>>
> > >>
> > 
> > >>
> >
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/4.0.0-tentative
> >  Maven Artifacts:
> > 
> > >>>
> > >>
> > 
> > >>
> >
> https://repository.apache.org/content/repositories/orgapachecassandra-1244/org/apache/cassandra/cassandra-all/4.0.0/
> > 
> >  The Source and Build Artifacts, and Debian and RPM packages and
> >  repositories are available here:
> >  https://dist.apache.org/repos/dist/dev/cassandra/4.0.0/
> > 
> >  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://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/4.0.0-tentative
> >  [2]: NEWS.txt:
> > >>>
> > >>
> > 
> > >>
> >
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/4.0.0-tentative
> > 
> > 
> > >> -
> >  To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> >  For additional commands, e-mail: dev-h...@cassandra.apache.org
> > 
> > >>>
> > >>>
> > >>>
> > -
> > >>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > >>> For additional commands, e-mail: dev-h...@cassandra.apache.org
> > >>>
> > >>>
> > >>
> > 
> > 
> -
> >  To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> >  For additional commands, e-mail: dev-h...@cassandra.apache.org
> > 
> > 
> > >>
> > >>
> > >> -
> > >> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > >> For additional commands, e-mail: dev-h...@cassandra.apache.org
> > >>
> > >>
> > >
> > > --
> > > Branimir Lambov
> > > e. branimir.lam...@datastax.com
> > > w. www.datastax.com
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > For additional commands, e-mail: dev-h...@cassandra.apache.org
> >
> >
>
> --
> http://twitter.com/tjake
>

Re: [VOTE] Release Apache Cassandra 4.0.0 (take2)

[Jon Meredith]

-1 nb.

I'll open a JIRA with details later tonight or first thing tomorrow.

I've confirmed that the serialization and deserialization of FWD_FRM
on 4.0 nodes when communicating with pre-4.0 nodes is incorrect and
includes an incorrect single-byte address length. Additionally the
logic for whether to use the same messageid when forwarding or not
needs to include the base message id as well as the forwarding ids. If
there was a single node to forward onto, the forwarded request was not
being sent with the correct messageId.

On Fri, Jul 16, 2021 at 3:05 PM Jon Meredith  wrote:
>
> I'd like to request an extension to the vote. There's a possible issue
> with 4.0 instances serializing FWD_FRM message parameters to pre-4.0
> nodes that I'm investigating and need a little more time.
>
> On Thu, Jul 15, 2021 at 9:45 AM Sam Tunnicliffe  wrote:
> >
> > +1
> >
> > > On 13 Jul 2021, at 23:13, Mick Semb Wever  wrote:
> > >
> > > Proposing the test build of Cassandra 4.0.0 for release.
> > >
> > > sha1: 924bf92fab1820942137138c779004acaf834187
> > > Git: 
> > > https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/4.0.0-tentative
> > > Maven Artifacts:
> > > https://repository.apache.org/content/repositories/orgapachecassandra-1242/org/apache/cassandra/cassandra-all/4.0.0/
> > >
> > > The Source and Build Artifacts, and the Debian and RPM packages and
> > > repositories, are available here:
> > > https://dist.apache.org/repos/dist/dev/cassandra/4.0.0/
> > >
> > > 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://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/4.0.0-tentative
> > > [2]: NEWS.txt: 
> > > https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/4.0.0-tentative
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > > For additional commands, e-mail: dev-h...@cassandra.apache.org
> > >
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > For additional commands, e-mail: dev-h...@cassandra.apache.org
> >

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: [VOTE] Release Apache Cassandra 4.0.0 (take2)

[Jon Meredith]

I'd like to request an extension to the vote. There's a possible issue
with 4.0 instances serializing FWD_FRM message parameters to pre-4.0
nodes that I'm investigating and need a little more time.

On Thu, Jul 15, 2021 at 9:45 AM Sam Tunnicliffe  wrote:
>
> +1
>
> > On 13 Jul 2021, at 23:13, Mick Semb Wever  wrote:
> >
> > Proposing the test build of Cassandra 4.0.0 for release.
> >
> > sha1: 924bf92fab1820942137138c779004acaf834187
> > Git: 
> > https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/4.0.0-tentative
> > Maven Artifacts:
> > https://repository.apache.org/content/repositories/orgapachecassandra-1242/org/apache/cassandra/cassandra-all/4.0.0/
> >
> > The Source and Build Artifacts, and the Debian and RPM packages and
> > repositories, are available here:
> > https://dist.apache.org/repos/dist/dev/cassandra/4.0.0/
> >
> > 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://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/4.0.0-tentative
> > [2]: NEWS.txt: 
> > https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/4.0.0-tentative
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > For additional commands, e-mail: dev-h...@cassandra.apache.org
> >
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: [VOTE] Release Apache Cassandra 4.0-rc2

[Jon Meredith]

+1 (nb)

On Mon, Jun 28, 2021 at 9:47 AM Yifan Cai  wrote:
>
> +1
>
>
> - Yifan
>
> > On Jun 28, 2021, at 8:40 AM, Ekaterina Dimitrova  
> > wrote:
> >
> > +1 Thanks everyone!
> >
> >> On Mon, 28 Jun 2021 at 11:39, Aleksey Yeschenko  wrote:
> >>
> >> +1
> >>
>  On 28 Jun 2021, at 14:05, Gary Dusbabek  wrote:
> >>>
> >>> +1; yay!
> >>>
>  On Sun, Jun 27, 2021 at 11:02 AM Mick Semb Wever  wrote:
> >>>
>  Proposing the test build of Cassandra 4.0-rc2 for release.
> 
>  sha1: 4c98576533e1d7663baf447e8877788096489165
>  Git:
> 
> 
> >> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/4.0-rc2-tentative
>  Maven Artifacts:
> 
> 
> >> https://repository.apache.org/content/repositories/orgapachecassandra-1237/org/apache/cassandra/cassandra-all/4.0-rc2/
> 
>  The Source and Build Artifacts, and the Debian and RPM packages and
>  repositories, are available here:
>  https://dist.apache.org/repos/dist/dev/cassandra/4.0-rc2/
> 
>  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://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/4.0-rc2-tentative
>  [2]: NEWS.txt:
> 
> 
> >> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/4.0-rc2-tentative
>  [3]: The maven artifacts were accidentally prematurely made public. Docs
>  have been updated to prevent this happening again.
> 
> >>
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> >> For additional commands, e-mail: dev-h...@cassandra.apache.org
> >>
> >>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: [VOTE] Release Apache Cassandra 4.0-rc1 (take2)

[Jon Meredith]

+1 (nb)

On Thu, Apr 22, 2021 at 7:59 AM Brandon Williams  wrote:
>
> +1
>
> On Wed, Apr 21, 2021 at 1:58 PM Mick Semb Wever  wrote:
> >
> > Proposing the test build of Cassandra 4.0-rc1 for release.
> >
> > sha1: 3282f5ecf187ecbb56b8d73ab9a9110c010898b0
> > Git: 
> > https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/4.0-rc1-tentative
> > Maven Artifacts:
> > https://repository.apache.org/content/repositories/orgapachecassandra-1235/org/apache/cassandra/cassandra-all/4.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/4.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://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/4.0-rc1-tentative
> > [2]: NEWS.txt: 
> > https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/4.0-rc1-tentative
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > For additional commands, e-mail: dev-h...@cassandra.apache.org
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: [VOTE][RESULT] Release Apache Cassandra 4.0-rc1

[Jon Meredith]

We may also want to wait for CASSANDRA-16524 given it has been
reproduced for a susceptible certificate configuration and would
prevent internode messaging from being established after the upgrade.

On Thu, Apr 1, 2021 at 7:29 AM Mick Semb Wever  wrote:
>
> With Marcus' binding veto, on technical grounds, the vote fails.
>
> I'll cut 4.0-rc1 again, once CASSANDRA-16552 lands.

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Cassandra 4.0 Status 2020-12-07

[Jon Meredith]

It's been three weeks since the last status update, so here's where we are.

Jira board with 4.0 scope:
https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=355=1661

High level numbers by release phase:

Alpha: 1 (-1 from last update); Last ticket from alpha,
CASSANDRA-13701 lowering default num_tokens in review, related to the
CASSANDRA-16079 Improve dtest runtime.

Beta: 55 (+2 from last update); 31 in-flight, no blockers. 15 tasks
show up in the 7-day stall.

RC: 20 (-6 from last update);

Created vs. resolved continues to trend positively:
https://issues.apache.org/jira/secure/ConfigureReport.jspa?projectOrFilterId=filter-12347782=daily=45=true=major=12310865=com.atlassian.jira.jira-core-reports-plugin%3Acreatedvsresolved-report_token=A5KQ-2QAV-T4JA-FDED_a3bea645259beee42ed00c68f87626d5972705c4_lin=Next


Where you can help:

* Each filter referenced below depends on accurate assignments in
Jira. In addition to actively assigning something you’re working on,
it would also be helpful to review and unassign (both Reviewer and
Assignee) things that you have assigned but may not be able to work on
in the release timeline.

Here’s a query to check that for yourself:

https://issues.apache.org/jira/issues/?filter=12348585=project%20%3D%20cassandra%20AND%20fixversion%20in%20(4.0%2C%204.0.0%2C%204.0-alpha%2C%204.0-beta%2C%204.0-rc%2C%204.0-alpha1%2C%204.0-alpha2%2C%204.0-alpha3%2C%204.0-alpha4%2C%204.0-alpha5%2C%204.0-alpha6%2C%204.0-beta-1%2C%204.0-beta1%2C%204.0-beta2%2C%204.0-beta3%2C%204.0-beta4)%20AND%20(resolution%20%3D%20unresolved%20OR%20status%20!%3D%20resolved)%20and%20(assignee%20%3D%20currentUser()%20or%20reviewer%20%3D%20currentUser()%20or%20reviewers%20%3D%20currentUser())%20

*Needs Reviewer:

1 Beta and 1 RC issues are awaiting review without reviewers.

Timely reviews here obviously keep things flowing, and help by keeping
the changes fresh in the patch contributor’s mind.

https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=355=1661=1659

*No assignee:

10 Beta and 4 RC issues

Please take a look and see if it’s within your capacity to take any of these on:
https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=355=1661=1658

*Test analysis and shepherding. We possibly have a fair amount of
unaccounted scope in the Quality/Test tickets that have not been
analyzed and expanded into subtasks.

https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=355=1939

Anything we can do to expedite that will give us a better picture of
what’s left, as well as allow us to parallelize test creation. Good
examples of those that have been broken down are the metrics and
tooling areas:

https://issues.apache.org/jira/browse/CASSANDRA-15582
https://issues.apache.org/jira/browse/CASSANDRA-15583

There are numerous similar tickets remaining.

*Tickets stalled for a week:

1 alpha, 10 beta, 8 GA

https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=355=1661=1694


Please let us know on the thread if I have missed anything that needs
attention. I encourage anyone to respond to these reports calling
attention to any localized things that could use it.

As always thanks to everyone for the continued work on the project.

-Jon Meredith

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: [VOTE] Release dtest-api 0.0.7

[Jon Meredith]

+1 (nb)

On Thu, Dec 3, 2020 at 6:02 AM Oleksandr Petrov
 wrote:
>
> Proposing the test build of in-jvm dtest API 0.0.7 for release.
>
> Repository:https://gitbox.apache.org/repos/asf?p=cassandra-in-jvm-dtest-api.git;a=shortlog;h=refs/tags/0.0.7
>
> Candidate 
> SHA:https://github.com/apache/cassandra-in-jvm-dtest-api/commit/d5174b1f44b7d9cb919d4975b4d437041273c09c
> tagged with 0.0.7
> Artifact:https://repository.apache.org/content/repositories/orgapachecassandra-1225/org/apache/cassandra/dtest-api/0.0.7/
>
> Key signature: 9E66CEC6106D578D0B1EB9BFF1000962B7F6840C
>
> Changes since last release:
>
>   * CASSANDRA-16136: Add Metrics to instance API
>   * CASSANDRA-16272: Nodetool assert apis do not include the new
> stdout and stderr in the failure message
>
> The vote will be open for 24 hours. 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.
>
> -- Alex

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

TLS protocol configuration for secure internode messaging needs improvement before the final 4.0 release

[Jon Meredith]

I didn't receive any feedback on the previous email I sent about this
on September 23rd. A couple of people pointed out the email got
flagged as suspicious so I've updated the an older JIRA that captures
the same problem instead.

https://issues.apache.org/jira/browse/CASSANDRA-13325

Please take a look if you have experience or interested in restricting
TLS protocol versions and logging of configured/active
protocols/ciphers.

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: [VOTE] Release dtest-api 0.0.5

[Jon Meredith]

+1 (non-binding)

On Fri, Sep 25, 2020 at 9:16 AM Marcus Eriksson  wrote:
>
> +1
>
> On 25 September 2020 at 17:13:36, Chris Lohfink (clohfin...@gmail.com) wrote:
> > +1
> >
> > On Fri, Sep 25, 2020 at 10:11 AM Caleb Rackliffe
> > wrote:
> >
> > > +1
> > >
> > > On Fri, Sep 25, 2020 at 10:08 AM Brandon Williams
> > > wrote:
> > >
> > > > +1
> > > >
> > > > On Fri, Sep 25, 2020, 9:45 AM Oleksandr Petrov <
> > > oleksandr.pet...@gmail.com
> > > > >
> > > > wrote:
> > > >
> > > > > Proposing the test build of in-jvm dtest API 0.0.5 for release.
> > > > >
> > > > > Repository:
> > > > >
> > > > >
> > > >
> > > https://gitbox.apache.org/repos/asf?p=cassandra-in-jvm-dtest-api.git;a=shortlog;h=refs/tags/0.0.5
> > > > > Candidate SHA:
> > > > >
> > > > >
> > > >
> > > https://github.com/apache/cassandra-in-jvm-dtest-api/commit/f900334d2f61f0b10640ba7ae15958f26df72d92
> > > > > tagged with 0.0.5
> > > > > Artifact:
> > > > >
> > > > >
> > > >
> > > https://repository.apache.org/content/repositories/orgapachecassandra-1219/org/apache/cassandra/dtest-api/0.0.5/
> > > > >
> > > > > Key signature: 9E66CEC6106D578D0B1EB9BFF1000962B7F6840C
> > > > >
> > > > > Changes since last release:
> > > > >
> > > > > * CASSANDRA-16109: If user has not set nodeCount, use the node id
> > > > > topology size
> > > > > * CASSANDRA-16057: Update in-jvm dtest to expose stdout and stderr
> > > for
> > > > > nodetool
> > > > > * CASSANDRA-16120: Add ability for jvm-dtest to grep instance logs
> > > > > * CASSANDRA-16101: Add method to ignore uncaught throwables
> > > > > * CASSANDRA-16109: Collect dc/rack information and validate when
> > > > building
> > > > > * CASSANDRA-15386: Default to 3 datadirs in in-jvm dtests
> > > > > * CASSANDRA-16101: Add method to fetch uncaught exceptions
> > > > >
> > > > > The vote will be open for 24 hours. 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.
> > > > >
> > > > > -- Alex
> > > > >
> > > >
> > >
> >
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

TLS protocol configuration for secure internode messaging needs improvement before the final 4.0 release.

[Jon Meredith]

tl;dr Setting encryption_options.protocol does not control which TLS
protocols are accepted, only restricting cipher_suites by protocol
does and I think we should fix encryption_options.protocol to actually
restrict, and have a proposal to do so at the end of the email.


I've been investigating restricting the TLS protocols to prevent use
of TLSv1 & TLSv1.1 for secure internode messaging and streaming
connections and think the current implementation needs improvement
before the final 4.0 release.

The Apache Cassandra documentation page on security
https://cassandra.apache.org/doc/latest/operating/security.html
mentions

"...  the JVM defaults for supported protocols and cipher suites are
used when encryption is enabled. These can be overidden using the
settings in cassandra.yaml, but this is not recommended unless there
are policies in place which dictate certain settings or a need to
disable vulnerable ciphers or protocols in cases where the JVM cannot
be updated."

The implication to me there is that the preferred mechanism is to
configure the JSSE subsystem. Trawling through documentation, the
operator can disable older TLS protocol at the JVM level by creating
new security properties file

$ cat conf/cassandra-security.properties
jdk.tls.disabledAlgorithms=SSLv3, RC4, DES, MD5withRSA, DH keySize < 1024, \
EC keySize < 224, 3DES_EDE_CBC, anon, NULL, TLSv1, TLSv1.1

And appending to the current security properties using

  -Djava.security.properties=conf/cassandra-security.properties.

This works fine pre-4.0, however the introduction of Netty tcnative
which uses OpenSSL under the hood, does not use the
java.security.properties to restrict anything. Neither does it
implement the calls for supporting the OpenSSL configuration file. It
only seems possible to restrict the protocol & ciphers through the
Netty SSLContext API. It is possible to disable OpenSSL by setting the
Java system property cassandra.disable_tcactive_openssl=true, but it
seems undesirable to lose the performance benefit there.

Looking in cassandra.yaml, under 'More advanced defaults' there is a
‘protocol' setting, which an operator might expect restricts which TLS
protocols are accepted.

# More advanced defaults:
# protocol: TLS

However, setting that to TLSv1.2 had no effect on the protocols the
server accepted. Running "openssl s_client -tlsv1 -connect
127.0.0.1:7000" will connect without issue and negotiate a TLSv1.0
session.

I found two previous tickets that addressed TLS protocols, first
explicitly hard-coding the accepted TLS protocols to disable SSLv3
(due to POODLE) in CASSANDRA-8265 /
b93f48a5db321bf7c9fb55a800ed6ab2d6f6b102, and then rely back on Java8
defaults in CASSANDRA-10508 / e4a0a4bf65a87c3aabae4ee0cc35009879e2d455
once they were fixed.

CASSANDRA-10508 mentions the ‘protocol' field as a mechanism for
specifying the protocol, however according to Java docs, that only
verifies the protocol is to the SSL engine supported, and does not
restrict negotiation to using it, as the openssl s_client test
demonstrates.

>From a quick search of the internet, a couple of blog posts recommend
setting the cipher suite to only TLSv1.2 valid ciphers and I can
confirm that does work, leading to this being logged (at ERROR).

ERROR [Messaging-EventLoop-3-2] 2020-09-19T16:17:48,023 : - Failed to
properly handshake with peer /127.0.0.1:33826. Closing the channel.
io.netty.handler.codec.DecoderException:
javax.net.ssl.SSLHandshakeException: Client requested protocol TLSv1.1
is not enabled or supported in server context
Caused by: javax.net.ssl.SSLHandshakeException: Client requested
protocol TLSv1.1 is not enabled or supported in server context

While it does work to restrict the protocol, if we start logging the
accepted protocols the log will show that the server will negotiate
TLS1/TLS1.1 which may get flagged by anybody validating the operators
secure connection configuration.

I also discovered that if SSL is misconfigured (ciphers, keystone,
truststore etc), the node will start up happily but be unable to
accept or make any secure internode connections.

The current state of the code and documentation is unsatisfactory to
me.  We should at least improve the documentation to give clear
guidance to operators on how they can secure their systems under
4.0/tcnative, however I think we should go further and make the
encryption_option.protocol field behave as intended.

Here's my proposal:

1) Interpret the current protocol string as a comma separated list of
protocols that are accepted. Replace the default
EncryptionOptions.protocol of "TLS" with null.
2) If protocol is non-null, call SslContextBuilder.protocols() with
the configured protocols in
org.apache.cassandra.security.SSLFactory#createNettySslContext
3) Special case the protocol configuration "TLS" to mean {"TLSv1",
"TLSv1.1", "TLSv1.2”} for users that have uncommented the default
value. Passing “TLS” is invalid in the protocols() call.
4) Hard-code 

Re: [VOTE] Accept the Harry donation

[Jon Meredith]

+1 (non-binding)

On Wed, Sep 16, 2020 at 8:28 AM David Capwell
 wrote:
>
> +1
>
> Sent from my iPhone
>
> > On Sep 16, 2020, at 6:34 AM, Brandon Williams  wrote:
> >
> > +1
> >
> >> On Wed, Sep 16, 2020, 4:45 AM Mick Semb Wever  wrote:
> >>
> >> This vote is about officially accepting the Harry donation from Alex Petrov
> >> and Benedict Elliott Smith, that was worked on in CASSANDRA-15348.
> >>
> >> The Incubator IP Clearance has been filled out at
> >> http://incubator.apache.org/ip-clearance/apache-cassandra-harry.html
> >>
> >> This vote is a required part of the IP Clearance process. It follows the
> >> same voting rules as releases, i.e. from the PMC a minimum of three +1s and
> >> no -1s.
> >>
> >> Please cast your votes:
> >>   [ ] +1 Accept the contribution into Cassandra
> >>   [ ] -1 Do not
> >>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: Feedback request on minor JMX interface incompatibility for CASSANDRA-15937

[Jon Meredith]

Thanks for the feedback, given three +1s and no objections then I'll
move on to get it merged.

I'm satisfied with the code and David Capwell has completed his
review. If another contributor with more experience with how JMX is
used in the community could look (particularly somebody with operator
experience) that would be greatly appreciated.

On Thu, Aug 6, 2020 at 5:56 AM Benedict Elliott Smith
 wrote:
>
> +1
>
> On 06/08/2020, 10:07, "Michael Semb Wever"  wrote:
>
>
> > I think the pragmatic thing to do is fix it now, and I'd strongly
> > prefer to do that but wanted to check if there are any objections or
> > things I hadn't considered?
>
>
> +1
>
> Thanks for giving this visibility and demonstrating we are serious about 
> the beta test cycle.
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Feedback request on minor JMX interface incompatibility for CASSANDRA-15937

[Jon Meredith]

Following up on Mick's email about interface incompatible changes,
CASSANDRA-15937 is ready for review. In my opinion, this just fixes
some bugs in CASSANDRA-7544 patch that slipped through the original
review, but before we review & merge fixes I wanted to ask if anybody
had any objections to merging it at this stage.

The ticket has more details, but to recap when InetAddressAndPort was
introduced in CASSANDRA-7544 so that nodes can share the same IP
address with different storage ports, new versions of status Mbeans
were added that included the port so as not to break anything that
didn't expect a port number. Unfortunately the change introduced
inconsistencies in how the host address is formatted between the old
and new versions. It also updated some per-connection metrics which
are also affected.

Before CASSANDRA-7544, describing host addresses either used
InetAddress.toString which formats as "/" or
InetAddress.getHostAddress which just provides a numeric address.
InetAddressAndPort was introduced with only a toString() method that
just provided the numeric address and port number, but did not provide
an equivalent getHostAddress/getHostAddressAndPort methods.  The
updated versions of all the JMX endpoints all called toString and
dropped the resolved names.

CASSANDRA-15937 adds an implementation of getHostAddressAndPort and
reverts the getHostAddress to toString conversions, giving consistent
formatting between the two versions, but with the port number.  This
has the following impact (with a couple of other minor bugs fixed).

1) AllEndpointStats, SimpleStates, Connection message tracking,
TimeoutsPerHost now include the [host]/ip:port in the WithPort version
2) Correct LoadMap to omit port (fixes backward compatibility)
LoadMapWithPort to include port (which was missing)
3) Ownership - update WithPort to include the [host]/ip:port version
4) Scores - update WithPort to [host]/ip:port version

It's a shame we didn't discover/resolve it before we cut beta1 as it
does change things by introducing "[host]/" in some places, however
this is only in 4.0 related fields that were just introduced.

The alternatives to merging I can see are

1) Do nothing for the 4.0 release and have the new WithPort versions
broken until we fix in a new major.
2) Introduce a third-version of the naming with things fixed
(WithPort_2 or something awful)
3) Reduce scope - don't 'fix' all the bare host addresses, just fix
LoadMap as it is the only one that is actually *wrong*, rather than
different. Perhaps the resolved name before the slash is annoying to
people.

I think the pragmatic thing to do is fix it now, and I'd strongly
prefer to do that but wanted to check if there are any objections or
things I hadn't considered?

Cheers, Jon.

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: [RELEASE] Apache Cassandra 4.0-beta1 released

[Jon Meredith]

(dropping user)

It's probably also worth mentioning that CASSANDRA-15937 will impact
what gets received on some of the JMX endpoints related to including
storage ports along with addresses, but all of the changes I view as
bugfixes on the original rather than any new functionality (for
example LoadMap / LoadMap with port outputs should be swapped and
ownership/scores are inconsistently formatted).

I expect to have a patch posted for it today, but please get in touch
if anybody has concerns about the changes.


On Fri, Jul 24, 2020 at 8:56 AM Mick Semb Wever  wrote:
>
> > This version is a beta release[1] on the 4.0 series. As always, please
> > pay attention to the release notes[2] and let us know[3] if you were
> > to encounter any problem.
>
>
>
> A quick followup note to both user and dev groups.
>
> Our Beta release guidelines¹ states that there will be no further API
> changes leading up to 4.0 GA.
> But we do currently have in place three planned exceptions to this, found in
> the following tickets:
>
> - CASSANDRA-15299 –  "CASSANDRA-13304 follow-up: improve checksumming and
> compression in protocol v5-beta"
> - CASSANDRA-15234 – Standardise config and JVM parameters
> - CASSANDRA-13701 – Lower default num_tokens
>
>
> The API changes to these are minimal, and part of the reason these were
> allowed to slip into the beta phase.
> For example…
> * CASSANDRA-15299 only affects those that are using the not yet stabilised
> v5 native protocol.
> * CASSANDRA-15234 will introduce cleaner, easier to use, cassandra.yaml
> settings, but all existing yaml setting names will still work.
> * CASSANDRA-13701 will change the default num_tokens setting to 16 (from
> 256), a change that will only impact provisioning of new clusters (because
> existing clusters must configure any new nodes to use the existing
> num_tokens value).
>
> All three tickets have fixVersion still set to `4.0-alpha` because of this
> situation.
>
>
> References:
>  [1] https://cwiki.apache.org/confluence/display/CASSANDRA/Release+Lifecycle

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: [DISCUSS] Revisiting Java 11's experimental status

[Jon Meredith]

The majority of the testing that I'm doing and likely the people I
work with day to day tests 4.0 on Java 11, so we should gain some
experience over the next few months.

On Mon, Jul 13, 2020 at 5:27 PM Sumanth Pasupuleti
 wrote:
>
> We at Netflix have been testing 4.0 on Java 8, and we do not plan to
> use Java 11 yet for C*, since we are, and for the considerable future will
> be running Java 8 only in production.
>
> On Mon, Jul 13, 2020 at 2:41 PM Patrick McFadin  wrote:
>
> > JDK8 seems like the safe devil we know, but in the interest of trying to
> > gather a bit of data, I just posted a twitter poll.
> >
> > https://twitter.com/patrickmcfadin/status/1282791302065557504?s=21
> >
> >
> > On Mon, Jul 13, 2020 at 12:26 PM Elliott Sims 
> > wrote:
> >
> > > Personally, I'd planned to upgrade to 4.0 on JDK8 but only wait a few
> > weeks
> > > before starting to update to JDK11 afterwards.  Everything else we run's
> > > been updated to JDK11, so the Cassandra clusters are the odd one out at
> > > this point.
> > >
> > > On Mon, Jul 13, 2020 at 12:19 PM Jordan West  wrote:
> > >
> > > > Thanks for bringing this up Jon! My current thinking is we should
> > > > officially support both 8 and 11. That increases the surface area we
> > need
> > > > to test but I think its hard to predict what different users will run
> > > given
> > > > the current transition in the Java landscape.
> > > >
> > > > Jordan
> > > >
> > > > On Mon, Jul 13, 2020 at 11:42 AM Jon Haddad  wrote:
> > > >
> > > > > Support for Java 11 was added a long time ago, and it's been about 2
> > > > years
> > > > > since it was released (Sept 2018).  Had we released Cassandra 4 close
> > > to
> > > > > that date, I'd be fine with keeping the status as experimental, but
> > at
> > > > this
> > > > > point I'm wondering if releasing a new major version of C* that's
> > > > primarily
> > > > > targeting Java 8 as the only "official" supported version is a good
> > > idea.
> > > > >
> > > > > To those of you that are planning on rolling out C* 4.0, are you
> > > planning
> > > > > on using Java 8 still, or moving to 11?  Speaking for myself, I can
> > > say I
> > > > > don't think I'd want to use 8 anymore.  If most folks are testing
> > with
> > > 11
> > > > > at this point, I think we should consider making 11 the recommended
> > > > version
> > > > > and really only encouraging Java 8 for legacy purposes - teams who
> > > have a
> > > > > restriction that prevents them from upgrading.
> > > > >
> > > > > To those of you planning on moving to 4.0 soon after it's release,
> > are
> > > > you
> > > > > planning on deploying to JDK 11 or 8?
> > > > >
> > > > > [1]
> > > > https://www.oracle.com/java/technologies/java-se-support-roadmap.html
> > > > >
> > > >
> > >
> >

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

20200623 Cassandra 4.0 Status

[Jon Meredith]

Hi Everyone,

[Board]
The board can be found here:
https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=355

[New Tickets]
In the last 7 days we have opened 6 new tickets (2 alpha, 3 beta, 1 rc) and
closed 13 (8 alpha, 4 beta, 1 rc).

Please remember to be thoughtful about what Fix Version you assign
a ticket to as we get closer to being able to release beta1.

https://cwiki.apache.org/confluence/display/CASSANDRA/Release+Lifecycle

[Tickets That Need Attention]

All the remaining alpha issues are being worked on (C-15146 is blocked
on C-15234).
There are 32 beta issues that need attention.

https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=355=1719


[Needs Reviewer]
2 tickets assigned are looking for reviewers:
- https://issues.apache.org/jira/browse/CASSANDRA-15229: BufferPool
Regression
- https://issues.apache.org/jira/browse/CASSANDRA-13047 Point cqlsh
help to the new doc


[Alpha Status]
There are 7 tickets not marked Resolved that are assigned to Alpha (down from
7 at the time of the last status update two weeks ago). The issues are
comprised of
interface-breaking changes, flaky tests, and a critical bug.


[Beta Status]
There are 45 issues not marked Resolved that are assigned to Beta (up from 32
at the time of the last status update two weeks ago).

About one third are fixes to code or tests and the other two thirds
are more general
quality related/tracking down flaky test tasks.

[Cumulative Flow Diagram]
A visual measure of our progress can be found here:
https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=355=CASSANDRA=reporting=cumulativeFlowDiagram=939=936=931=1505=1506=1514=1509=1512=1507=2020-04-07=2020-04-28

Thanks everyone!
Jon

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

20200609 Cassandra 4.0 Status Update

[Jon Meredith]

Hi Everyone,

[Board]
The board can be found here:
https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=355

[New Tickets]
In the last seven days we have opened three new alpha tickets, two of which
closed already and seven beta tickets, one closed, two in review.

Please remember to be thoughtful about what Fix Version you assign
a ticket to as we get closer to being able to release beta1.

https://cwiki.apache.org/confluence/display/CASSANDRA/Release+Lifecycle

In good news, thirteen were closed. (nine alpha, three beta, one rc)

[Tickets That Need Attention]
In alpha, server_encryption_options and expose table schema have been
quiet for a while (see Alpha Status)

[Needs Reviewer]

2 tickets assigned to Beta are looking for reviewers:
 - https://issues.apache.org/jira/browse/CASSANDRA-15229 BufferPool Regression
 - https://issues.apache.org/jira/browse/CASSANDRA-13047 Point cqlsh
help to the new doc

[Alpha Status]

We are down to 7 tickets tagged against 4.0-alpha after the recent
triage... this might really be it.

Four of which are in review/cleanup.
 - (active today) CASSANDRA-15677 Topology events are not sent to
clients if the nodes use the same network interface
 - (active today) CASSANDRA-15234 Standardise config and JVM parameters
 - (last update 30th May) CASSANDRA-15262 server_encryption_options is
not backwards compatible with 3.11
 - (last update 6th May) CASSANDRA-14825 Expose table schema for drivers

Two API / Configuration / Protocol changes
 - CASSANDRA-15146 Transitional TLS server configuration options are
overly complex
   should close after C-15234 lands, rename server_encryption_options
to internode_encryption_options.
 - CASSANDRA-15299 follow-up: improve checksumming and compression in
protocol v5-beta

One flaky test issue / bug
 - CASSANDRA-15863 dtest failure TestReplaceAddress.test_restart_failed_replace


[Beta Status]
There are 32 issues not marked done that are assigned to Beta (down from 41
at the time of the last status update). These tickets are primarily
comprised of the testing epic work, known regressions, planned
improvements, and flaky tests.

[Cumulative Flow Diagram]
A visual measure of our progress can be found here:
https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=355=CASSANDRA=reporting=cumulativeFlowDiagram=939=936=931=1505=1506=1514=1509=1512=1507=2020-04-07=2020-04-28

Thanks everyone!
Jon

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: Calling for release managers (Committers and PMC)

[Jon Meredith]

Sign me up.

On Thu, May 7, 2020 at 12:36 PM Robert Stupp  wrote:
>
> I can help
>
> --
> Robert Stupp
> @snazy
>
> > Am 07.05.2020 um 20:29 schrieb Mick Semb Wever :
> >
> > The Cassandra release process has had some improvements to better in
> > line with the ASF guidelines: sha256 & sha512 checksums, staged
> > artefacts in svnpubsub, dep and rpm repositories complete and signed
> > in staging, and separate scripts and manual steps merged together.
> >
> > The updated documentation for cutting, voting, and publishing a
> > release is found here:
> > https://cassandra.apache.org/doc/latest/development/release_process.html
> >
> > I am hoping to get as many Committers* and PMC members interested as
> > possible for cutting a future release.
> >
> > Who is interested? How many names can I get :-)
> >
> > The more that are interested then the easier it is to take turns and
> > be flexible depending on our own availability each time. I will help
> > out everyone on their first run. Indeed most of my motivation in
> > getting involved with the release process was to make it all as simple
> > and as forgettable as possible, so the role of the role manager can
> > change easily from release to release.
> >
> > *When a Committer cuts a release, a PMC member has to perform the very
> > last post-vote publish step.
> >
> > regards,
> > Mick
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > For additional commands, e-mail: dev-h...@cassandra.apache.org
> >
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

20200505 Cassandra 4.0 Status Update

[Jon Meredith]

The board can be found here:
https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=355

[LHF]
https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=355=CASSANDRA=1661=1726=1658

[Tickets That Need Attention]
https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=355=CASSANDRA=1723=1719

We have 8 beta issues that are in the "Needs Attention" (stalled, needs
reviewer) bucket. While not as pressing as the Alpha tickets, please raise
a flag if you could use some help either on collaboration or on a review

[Alpha Status]
https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=355=CASSANDRA=1723

We have 9 tickets not marked as 'done' for 4.0-alpha.  7 of them
are related to flaky tests.  Of the remaining I think one can be
deferred to 4.0-beta and have pinged the reporter, which leaves
just 2.

(In Progress) CASSANDRA-15262 server_encryption_options is not
backwards compatible with 3.11
(In Review)   CASSANDRA-15674 liveDiskSpaceUsed and totalDiskSpaceUsed
get corrupted if IndexSummaryRedistribution gets interrupted

We are so close to being able to cut the first beta.

[Beta Status]

Referencing the above link, we have 15 bugs or tasks in beta. 8 of those
are the Needs Attention referred to above and we have 6 that are backlogged
in ToDo status. If you have tickets assigned to you that are flagged beta
but don't currently have cycles to work on them, consider pinging in the
#cassandra-dev channel on slack or hitting up the dev ML to see if there's
anyone else with interest and cycles to help out there.


[Needs Reviewer]

https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=355=CASSANDRA=detail=CASSANDRA-15560=1661=1659

Just one! A docs PR CASSANDRA-15749 Make clear in the documentation
that stress is not a secured tool


[Open vs. Closed Last 21 Days & Cumulative Flow]
https://issues.apache.org/jira/secure/ConfigureReport.jspa?projectOrFilterId=filter-12348585=daily=21=true=major=12310865=com.atlassian.jira.jira-core-reports-plugin%3Acreatedvsresolved-report_token=A5KQ-2QAV-T4JA-FDED_9340412df581ebf97c07577c653b8288843dc555_lin=Next

After a few weeks of closing more tickets than were opened, things are
flattening off to closing about as many as we open. Nothing to be
worried about, looks like reporting things that are being found and
fixed.

The Cumulative Flow Diagram:
https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=355=CASSANDRA=reporting=cumulativeFlowDiagram=939=936=931=1505=1506=1514=1509=1512=1507=2020-04-07=2020-04-28


[Icebergs]

(copying from Josh last week as it's worth re-stating)

There's 6 tickets in BLOCKED status in the rc release, all linked to the
40_Quality_Test epic, that I'm a little wary of. Those are probably our
largest unidentified and unspecified scope outstanding to hitting a 4.0 GA,
but they're also incredibly important for us to "do right" as a project in
order to have 4.0 be a truly stable and production ready release. If you
have a point of view on those tickets, please take a little time to share
that PoV on there and help unstick them, since there are contributors
available to be executing on those tests in parallel while we're executing
on closing up our alpha and beta phases.


Thanks for all the hard work through the least glamorous part of shipping...

Jon.

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

20200331 4.0 status update

[Jon Meredith]

Hello dev@cassandra, here is the state of 4.0 things.

Link to the JIRA board:
https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=355=CASSANDRA

Josh has added a new 'Needs Attention' filter to show any tasks that
are stalled, need an assignee or need a reviewer.  Makes it easy if
you'd like to find something to work on.

There are currently 19 issues tagged as alpha, with discussion taking
place on the mailing list on how to triage and track existing and
newly created issues so that we can get to a first beta.

[Open vs. Closed last 7 days]
We opened 13 new tickets in the last 7 days, four of them against the
alpha with one already committed and another approved, with the other
two progressing. Three against beta, six against the RC.

We closed 11 for a delta of +2, a minor uptick.

Opened:
https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=355=CASSANDRA=1670
Closed:
https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=355=CASSANDRA=1671

[Needs Assignee]
https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=355=CASSANDRA=1658=1661

Down from 14 to 11.  Three are related to broader release quality efforts.

[Needs Reviewer]
https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=355=CASSANDRA=1661=1659

3 alpha / 3 beta / 3 RC

A quick plug for the alpha tickets, patch available for your reviewing pleasure.

TEST https://issues.apache.org/jira/browse/CASSANDRA-15338 Fix flakey
testMessagePurging - org.apache.cassandra.net.ConnectionTest
BUG https://issues.apache.org/jira/browse/CASSANDRA-15674
liveDiskSpaceUsed and totalDiskSpaceUsed get corrupted if
IndexSummaryRedistribution gets interrupted
BUG https://issues.apache.org/jira/browse/CASSANDRA-15660 Unable to
specify -e/--execute flag in cqlsh

[Stalled: >14d no movement]
https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=355=CASSANDRA-15601=1661=1694

51 tickets tagged against 4.0 haven't been updated in the last 2
weeks, with four are marked to complete in alpha.

CASSANDRA-15262 server_encryption_options is not backwards compatible with 3.11
CASSANDRA-15624 Avoid lazy initializing shut down instances when
trying to send them messages
CASSANDRA-15551 Fix flaky tests org.apache.cassandra.service.MoveTest
testStateJumpToNormal and
testMoveWithPendingRangesNetworkStrategyRackAwareThirtyNodes
CASSANDRA-15601 Ensure repaired data tracking reads a consistent
amount of data across replicas [patch available!]

If you have any new info on those tickets, please update and share as
we're getting tantalizingly close to completing the alpha tasks.

[Cumulative Flow]
https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=355=reporting=cumulativeFlowDiagram=939=936=931=1505=1506=1514=1509=1512=1507=30

Up and to the right, what more could you ask. Continuing at about the
same rate as the last few weeks.
If you'd like to cheer yourself up about progress towards 4.0, zoom
out the overview over the last 12 months
and you can see how much faster things are moving now.


Once again, thanks for all the hard work everybody. Feedback is
welcome on these emails. Are they a helpful snapshot? Are they
motivating? Is it just noise on the dev list. Please let us know how
they can be improved.

Jon

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

2020-03-09 4.0 Status

[Jon Meredith]

Link to JIRA board:
https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=355=CASSANDRA

It's been a week of toiling on the tasks we need to ship a release --
fixing bugs and flaky tests.

We've had 0 new ticket opened against 4.0 since the last status email (6d).
https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=355=CASSANDRA=1661=1670

We've closed out 10 tickets since the last status email (6d)
https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=355=CASSANDRA=1671

For a delta of -10 total tickets, and a grand total of 98 tickets currently
unresolved.


The cumulative flow diagram continues to show healthy progress:
https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=355=CASSANDRA=reporting=cumulativeFlowDiagram=939=936=931=1505=1506=1514=1509=1512=1507=90

[Unassigned Tickets]

We have 2 alpha, 3 beta, 17 RC tickets without assigness.
https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=355=CASSANDRA=CASSANDRA-15338=1658=1661

A couple of test failures would be good to investigate, however the two
BufferPool tickets remain unassigned still.

CASSANDRA-15306: Investigate why we are allocating 8MiB chunks and reaching
the maximum BufferPool size
https://issues.apache.org/jira/browse/CASSANDRA-15306

Our current unassigned white whale from July of last year:
CASSANDRA-15229: BufferPool Regression
https://issues.apache.org/jira/browse/CASSANDRA-15229
The TL;DR from Benedict on the ticket: "The BufferPool was never intended
to be used for a ChunkCache, and we need to either change our behaviour to
handle uncorrelated lifetimes or use something else. "
So this one could be quite an interesting challenge for someone that knows
this portion of the codebase.


[Stuck tickets - needs reviewer]
https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=355=1661=1659
(removing tickets that have had discussion since the most recent patch was
made available and checked with a few assignees on Slack)

CASSANDRA-15565 Fix flaky test
org.apache.cassandra.index.internal.CassandraIndexTest
indexCorrectlyMarkedAsBuildAndRemoved -- it's fairly small.

[Notable tickets closed in the past week]

CASSANDRA-15338, CASSANDRA-15552, CASSANDRA-15613 fixes for flakey tests.
Fans of green CI runs can rejoice.

CASSANDRA-15476, CASSANDRA-15481, CASSANDRA-15353 docs for Transient
Replication and Data Modeling
and more.

CASSANDRA-15616 Expose Cassandra related system properties in a virtual
table


Thanks everyone for all your hard work.

Jon

20200217 4.0 Status Update

[Jon Meredith]

My turn to give an update on 4.0 status. The 4.0 board created by Josh can
be found at


https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=355.


We have 94 unresolved tickets marked against the 4.0 release. [1]


Things seem to have settled into a phase of working to resolve issues, with
few new issues added.


2 new tickets opened (that are marked against 4.0)

11 tickets closed (including one of the newly opened ones)

39 tickets received updates to JIRA of some kind in the last week


Cumulative flow over the last couple of weeks shows todo reducing and done
increasing as it should as we continue to close out work for the release.


https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=355=CASSANDRA=reporting=cumulativeFlowDiagram=939=936=931=1505=1506=1514=1509=1512=1507=14


Notables

 - Python 3 support for cqlsh has been committed (thank you all who
persevered on this)

 - Some activity on Windows support - perhaps not dead yet.

 - Lots of movement on documentation

 - Lots of activity on flaky tests.

 - Oldest ticket with a patch award goes to CASSANDRA-2848


There are 18 tickets marked as patch available (easy access from the
Dashboard [2], apologies if they're already picked up for review)


CASSANDRA-15567 Allow EXTRA_CLASSPATH to work in tarball/source
installations

CASSANDRA-15553 Preview repair should include sstables from finalized
incremental repair sessions

CASSANDRA-15550 Fix flaky test
org.apache.cassandra.streaming.StreamTransferTaskTest
testFailSessionDuringTransferShouldNotReleaseReferences

CASSANDRA-15488/CASSANDRA-15353 Configuration file

CASSANDRA-15484/CASSANDRA-15353 Read Repair

CASSANDRA-15482/CASSANDRA-15353 Guarantees

CASSANDRA-15481/CASSANDRA-15353 Data Modeling

CASSANDRA-15393/CASSANDRA-15387 Add byte array backed cells

CASSANDRA-15391/CASSANDRA-15387 Reduce heap footprint of commonly allocated
objects

CASSANDRA-15367 Memtable memory allocations may deadlock

CASSANDRA-15308 Fix flakey testAcquireReleaseOutbound -
org.apache.cassandra.net.ConnectionTest

CASSANDRA-1530 5Fix multi DC nodetool status output

CASSANDRA-14973 Bring v5 driver out of beta, introduce v6 before 4.0
release is cut

CASSANDRA-14939 fix some operational holes in incremental repair

CASSANDRA-14904 SSTableloader doesn't understand listening for CQL
connections on multiple ports

CASSANDRA-14842 SSL connection problems when upgrading to 4.0 when
upgrading from 3.0.x

CASSANDRA-14761 Rename speculative_retry to match additional_write_policy

CASSANDRA-2848 Make the Client API support passing down timeouts


*LHF / Failing Tests*: We have 7 unassigned test failures that are all

great candidates to pick up and get involved in:

https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=355=CASSANDRA=1660=1661=1658


Thanks again to everybody for all the contributions. It's really good to
see the open issue count start dropping.


Feedback on whether this information is useful and how it can be improved
is both welcome and appreciated.


Cheers, Jon


[1] Unresolved 4.0 tickets
https://issues.apache.org/jira/browse/CASSANDRA-15567?filter=12347782=project%20%3D%20cassandra%20AND%20fixversion%20in%20(4.0%2C%204.0.0%2C%204.0-alpha%2C%204.0-beta)%20AND%20status%20!%3D%20Resolved

[2] Patch Available
https://issues.apache.org/jira/secure/Dashboard.jspa?selectPageId=12334910

Re: [VOTE] Cassandra Enhancement Proposal (CEP) documentation

[Jon Meredith]

+1 nb

> On Nov 1, 2019, at 8:07 AM, Scott Andreas  wrote:
> 
> +1 nb
> 
>> On Nov 1, 2019, at 5:36 AM, Benedict Elliott Smith  
>> wrote:
>> 
>> +1
>> 
>> On 01/11/2019, 12:33, "Mick Semb Wever"  wrote:
>> 
>>   Please vote on accepting the Cassandra Enhancement Proposal (CEP) document 
>> as a starting point and guide towards improving collaboration on, and 
>> success of, new features and significant improvements. In combination with 
>> the recently accepted Cassandra Release Lifecycle documentation this should 
>> help us moving forward as a project and community.
>> 
>>   https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=95652201 
>> 
>>   Past discussions on the document/process have been touched on in a number 
>> of threads in the dev ML.  The most recent thread was 
>> https://lists.apache.org/thread.html/b5d1b1ca99324f84e4a40b9cba879e8f858f5f6e18447775fcf32155@%3Cdev.cassandra.apache.org%3E
>> 
>>   regards,
>>   Mick
>> 
>>   -
>>   To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
>>   For additional commands, e-mail: dev-h...@cassandra.apache.org
>> 
>> 
>> 
>> 
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
>> For additional commands, e-mail: dev-h...@cassandra.apache.org
>> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
> 


-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: [VOTE] Release Apache Cassandra 4.0-alpha2

[Jon Meredith]

The DatabaseDescriptorRefTest breakage is on me - there's a fix included as
part of CASSANDRA-15371.  Sorry for breaking it -  it's benign, just forgot
to add to the new DistributedTestSnitch to the validClasses list.

On Fri, Oct 25, 2019 at 11:06 AM Vinay Chella 
wrote:

> Unit test "*testDatabaseDescriptorRef -
> org.apache.cassandra.config.DatabaseDescriptorRefTest*" is consistently
> failing across different test suites -
> https://circleci.com/gh/vinaykumarchella/cassandra/487#tests/containers/37
>
> Java8 tests:
> https://circleci.com/workflow-run/b74a1510-9ce5-4d09-a448-0f9cb2a23350
> Java11
> 
> tests:
> https://circleci.com/workflow-run/9b23de5a-3c5b-41b4-88c4-3495b453eb53
>
> <
> https://circleci.com/gh/vinaykumarchella/cassandra/487#tests/containers/37
> >Following
> tests seems to be flaky, I will be rerunning to confirm and open JIRAs as
> needed.
>
> 1. testIdleDisconnect - org.apache.cassandra.transport.IdleDisconnectTest
> 2. test_drop_with_stopped_build -
> materialized_views_test.TestMaterializedViews
> 3. test_remote_query - cql_test.TestCQLSlowQuery
>
> Thanks,
> Vinay Chella
>
>
> On Fri, Oct 25, 2019 at 9:27 AM Blake Eggleston
>  wrote:
>
> > +1
> >
> > > On Oct 25, 2019, at 8:57 AM, Jeff Jirsa  wrote:
> > >
> > > +1
> > >
> > >
> > > On Fri, Oct 25, 2019 at 8:06 AM Jon Haddad  wrote:
> > >
> > >> +1
> > >>
> > >> On Fri, Oct 25, 2019 at 10:18 AM Sam Tunnicliffe 
> > wrote:
> > >>
> > >>> +1
> > >>>
> >  On 24 Oct 2019, at 18:26, Michael Shuler 
> > >> wrote:
> > 
> >  I propose the following artifacts for release as 4.0-alpha2.
> > 
> >  sha1: ca928a49c68186bdcd57dea8b10c30991c6a3c55
> >  Git:
> > >>>
> > >>
> >
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/4.0-alpha2-tentative
> >  Artifacts:
> > >>>
> > >>
> >
> https://repository.apache.org/content/repositories/orgapachecassandra-1185/org/apache/cassandra/apache-cassandra/4.0-alpha2/
> >  Staging repository:
> > >>>
> > >>
> >
> https://repository.apache.org/content/repositories/orgapachecassandra-1185/
> > 
> >  The Debian and RPM packages are available here:
> > >>> http://people.apache.org/~mshuler
> > 
> >  The vote will be open for 72 hours (longer if needed).
> > 
> >  [1]: CHANGES.txt:
> > >>>
> > >>
> >
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/4.0-alpha2-tentative
> >  [2]: NEWS.txt:
> > >>>
> > >>
> >
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/4.0-alpha2-tentative
> > 
> > 
> -
> >  To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> >  For additional commands, e-mail: dev-h...@cassandra.apache.org
> > 
> > >>>
> > >>>
> > >>> -
> > >>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > >>> For additional commands, e-mail: dev-h...@cassandra.apache.org
> > >>>
> > >>>
> > >>
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > For additional commands, e-mail: dev-h...@cassandra.apache.org
> >
> >
>

Re: [jira] [Commented] (CASSANDRA-15005) Configurable whilelist for UDFs

[Jon Meredith]

I don’t think it will need too much rewriting, and you’re welcome to give
it a go. However trunk is mostly feature frozen while it undergoes testing
ahead of release.

On Fri, Mar 15, 2019 at 9:43 AM A. Soroka (JIRA)  wrote:

>
> [
> https://issues.apache.org/jira/browse/CASSANDRA-15005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16793710#comment-16793710
> ]
>
> A. Soroka commented on CASSANDRA-15005:
> ---
>
> [~jmeredithco] I just realized that your branch being from the 3.0 line
> means it runs up against the code freeze for that branch. I didn't
> understand what you meant by writing "I'm also not sure what version this
> could land in with the current freeze on trunk." but now I see that there's
> a problem there. I can try rewriting this patch for {{trunk/4.0}} if you
> think that would be feasible/better?
>
> > Configurable whilelist for UDFs
> > ---
> >
> > Key: CASSANDRA-15005
> > URL:
> https://issues.apache.org/jira/browse/CASSANDRA-15005
> > Project: Cassandra
> >  Issue Type: Improvement
> >  Components: CQL/Interpreter
> >Reporter: A. Soroka
> >Priority: Low
> >
> > I would like to use the UDF system to distribute some simple
> calculations on values. For some use cases, this would require access only
> to some Java API classes that aren't on the (hardcoded) whitelist (e.g.
> {{java.security.MessageDigest}}). In other cases, it would require access
> to a little non-C* library code, pre-distributed to nodes by out-of-band
> means.
> > As I understand the situation now, the whitelist for types UDFs can use
> is hardcoded in java in [UDFunction|[
> https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/cql3/functions/UDFunction.java#L99]
> .]
> > This ticket, then, is a request for a facility that would allow that
> list to be extended via some kind of deployment-time configuration. I
> realize that serious security concerns immediately arise for this kind of
> functionality, but I hope that by restricting it (only used during startup,
> no exposing the whitelist for introspection, etc.) it could be quite
> practical.
> > I'd like very much to assist with this ticket if it is accepted. (I
> believe I have sufficient Java skill to do that, but no real familiarity
> with C*'s codebase, yet. :) )
>
>
>
> --
> This message was sent by Atlassian JIRA
> (v7.6.3#76005)
>
> -
> To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: commits-h...@cassandra.apache.org
>
>