Re: [DISCUSS] When to stop supporting Python 2

[Berenguer Blasi]

+1

On 22/1/21 21:14, Adam Holmberg wrote:
> As you may recall, CASSANDRA-10190 [1] introduced Python 3 support for
> cqlsh. This change will be landing in 4.0. In the course of development and
> discussion spanning years, it was decided to retain support for Python 2.
> In the meantime, Python 2 sunsetted (a year ago [2]). I hadn't seen a
> discussion about whether we intend to carry on support for Python 2, so I'm
> raising one here.
>
> 4.0 is a major release and we have an opportunity to drop support at this
> milestone. It has been mentioned that it will not be acceptable to do in a
> minor or patch release, so if it's not done for 4.0, we will need to wait
> for the next major. I do understand that many in the project would like
> majors on a more frequent interval post-4.0, but at this time we don't know
> when that will be.
>
> I advocate for dropping support ASAP. I expect that users should not be
> inconvenienced by this -- I am not aware of a major distro that has not had
> python3 for years. Dropping python2 support does not mean that we would do
> work to rip out python2-compatible code, just that we wouldn't advertise
> support and any package requirements would be adjusted. We benefit by
> removing the need to test multiple runtimes, and we wouldn't be concerned
> with fixing python2-specific issues that may arise on the EOL runtime [3].
>
> I look forward to the discussion.
>

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

Re: [DISCUSS] Revisiting the quality testing epic scope

[Alexander DEJANOVSKI]

I confirm we're almost done with CASSANDRA-15580 (Repair QA testing).
Nightly runs are scheduled already and I'm tuning some knobs to get them
nicely stable:
https://app.circleci.com/pipelines/github/riptano/cassandra-rtest?branch=trunk
Andres also created an in-jvm dtest for the mixed cluster repair test that
is under review.

Scope-wise, I'd suggest we keep the repair tests repo separate for now and
work on integrating it into the Cassandra codebase post-4.0. It could as
well be a separate repo altogether, depending on what would be the
consensus here.
I also had to reduce our ambitions on node density (from 100GB down to
20GB) due to how long the tests are taking already (almost 3 hours with
Full/Incremental/Subrange running in parallel, so that's roughly 6 hours of
AWS instance time per run when things go nicely). It's possible that the
test backup has too much entropy, but it may be a good thing as I'd rather
test smaller datasets with a lot of entropy rather than big ones with not
much. It already allowed to uncover CASSANDRA-16406
.

I'll update the tickets to reflect the current state.

Le jeu. 21 janv. 2021 à 23:23, Scott Andreas  a
écrit :

> Thanks Benjamin!
>
> I propose we de-scope 15538 as the ticket does not currently have a clear
> definition of done. Unless others disagree, we can remove the fix version
> via lazy consensus in a couple days. That leaves us with a well-defined set
> of tickets that are making progress.
>
> Re: the next question:
> "Do you have a timeframe in mind for releasing 4.0 GA? Assuming that there
> is no sudden burst in the number of issues."
>
> This is a great question for all on the list. Please consider what follows
> as my interpretation of our current status relative to the project's
> Release Lifecycle doc (and all "we/you" pronouns collective):
> https://cwiki.apache.org/confluence/display/CASSANDRA/Release+Lifecycle
>
> We're currently meeting all criteria for the Beta phase except "No flaky
> tests" and a small number of known bugs (eg., 16307, 16078). The good news
> is we have the tickets in both categories identified (discussed earlier in
> this thread), and they don't appear to be a large amount of work -
> potentially with the exception of CASSANDRA-16078: Performance regression
> for queries accessing multiple rows. The ticket reports a 39% perf
> regression for queries fetching multiple rows in a partition via IN clauses
> – a major regression that should block release until understood/fixed.
> Caleb's working on this now.
>
> Once those issues and the validation epics that are now in review are
> wrapped (which look like a few weeks' work if contributors can jump on the
> flaky test tickets), we'll have met our criteria for graduating beta.
>
> The definition of an RC release is that any SHA we cut an RC build from
> may legitimately be the SHA declared "Apache Cassandra 4.0.0." This is
> where it gets real. When the project declares a build "RC," we're staking
> our collective credibility on it and recommend that users upgrade to a
> build that received this designation.
>
> I feel very good about where 4.0 is at. We've all surfaced and resolved a
> large number of important issues. We've enhanced the project's testing
> infrastructure to broaden the surface covered, which reduces the
> probability of unknown unknowns. And we've collectively developed
> toolchains for large-scale verification, including of existing live
> clusters via diff.
>
> After beta’s complete, the next chasm to cross seems like our own
> collective willingness to deploy and operate Cassandra 4.0 clusters in
> production. Once we're at RC, willing to do so, and to recommend users do
> the same, I think we'll have hit our definition of done.
>
> As we wrap up the remaining beta issues and flaky tests, now's a good time
> for that RC gut check. If there's a remaining issue that would prevent you
> from running trunk in a prod environment, please file it and raise
> attention - it'll help us finish polishing the release. And if there isn't
> - deploy it!
>
> We still need to finish the remaining bugs in scope and get tests reliably
> green. But it feels good to be this close.
>
> – Scott
>
> 
> From: Benjamin Lerer 
> Sent: Tuesday, January 19, 2021 1:54 AM
> To: dev@cassandra.apache.org
> Subject: Re: [DISCUSS] Revisiting the quality testing epic scope
>
> Thank you for your reply, Scott.
>
> My understanding is that Alexander is moving forward on CASSANDRA-15580
> (Repair)  and that Andres is focussing with Caleb on the tickets of
> CASSANDRA-15579 (Distributed Read/Write Path). The biggest unknown here
> seems to be CASSANDRA-16262 as you mentioned.
>
> Regarding CASSANDRA-15582 (Metrics), I shifted my focus toward helping with
> reviews for the release candidate. By consequence, outside of 2 patches
> created by  Sumanth during the holidays, the epic has not been moving
> forward.

Re: [DISCUSS] When to stop supporting Python 2

[Ekaterina Dimitrova]

I support the idea,  we are not removing python2-compatible code
+1

On Fri, 22 Jan 2021 at 15:14, Adam Holmberg 
wrote:

> As you may recall, CASSANDRA-10190 [1] introduced Python 3 support for
> cqlsh. This change will be landing in 4.0. In the course of development and
> discussion spanning years, it was decided to retain support for Python 2.
> In the meantime, Python 2 sunsetted (a year ago [2]). I hadn't seen a
> discussion about whether we intend to carry on support for Python 2, so I'm
> raising one here.
>
> 4.0 is a major release and we have an opportunity to drop support at this
> milestone. It has been mentioned that it will not be acceptable to do in a
> minor or patch release, so if it's not done for 4.0, we will need to wait
> for the next major. I do understand that many in the project would like
> majors on a more frequent interval post-4.0, but at this time we don't know
> when that will be.
>
> I advocate for dropping support ASAP. I expect that users should not be
> inconvenienced by this -- I am not aware of a major distro that has not had
> python3 for years. Dropping python2 support does not mean that we would do
> work to rip out python2-compatible code, just that we wouldn't advertise
> support and any package requirements would be adjusted. We benefit by
> removing the need to test multiple runtimes, and we wouldn't be concerned
> with fixing python2-specific issues that may arise on the EOL runtime [3].
>
> I look forward to the discussion.
>
> --
> Adam Holmberg
> e. adam.holmb...@datastax.com
> w. www.datastax.com
>
> [1] https://issues.apache.org/jira/browse/CASSANDRA-10190
> [2] https://www.python.org/doc/sunset-python-2/
> [3] https://issues.apache.org/jira/browse/CASSANDRA-16400
>

Re: [DISCUSS] When to stop supporting Python 2

[Yifan Cai]

+1 nb.
We probably also want to set a milestone to get rid of the python2
compatible code completely, if we are going in the direction that drops
python2 support in 4.0 and retains the python2 compatible code. In 4.x or
5.0?

On Mon, Jan 25, 2021 at 9:24 AM Ekaterina Dimitrova 
wrote:

> I support the idea,  we are not removing python2-compatible code
> +1
>
> On Fri, 22 Jan 2021 at 15:14, Adam Holmberg 
> wrote:
>
> > As you may recall, CASSANDRA-10190 [1] introduced Python 3 support for
> > cqlsh. This change will be landing in 4.0. In the course of development
> and
> > discussion spanning years, it was decided to retain support for Python 2.
> > In the meantime, Python 2 sunsetted (a year ago [2]). I hadn't seen a
> > discussion about whether we intend to carry on support for Python 2, so
> I'm
> > raising one here.
> >
> > 4.0 is a major release and we have an opportunity to drop support at this
> > milestone. It has been mentioned that it will not be acceptable to do in
> a
> > minor or patch release, so if it's not done for 4.0, we will need to wait
> > for the next major. I do understand that many in the project would like
> > majors on a more frequent interval post-4.0, but at this time we don't
> know
> > when that will be.
> >
> > I advocate for dropping support ASAP. I expect that users should not be
> > inconvenienced by this -- I am not aware of a major distro that has not
> had
> > python3 for years. Dropping python2 support does not mean that we would
> do
> > work to rip out python2-compatible code, just that we wouldn't advertise
> > support and any package requirements would be adjusted. We benefit by
> > removing the need to test multiple runtimes, and we wouldn't be concerned
> > with fixing python2-specific issues that may arise on the EOL runtime
> [3].
> >
> > I look forward to the discussion.
> >
> > --
> > Adam Holmberg
> > e. adam.holmb...@datastax.com
> > w. www.datastax.com
> >
> > [1] https://issues.apache.org/jira/browse/CASSANDRA-10190
> > [2] https://www.python.org/doc/sunset-python-2/
> > [3] https://issues.apache.org/jira/browse/CASSANDRA-16400
> >
>

Re: [DISCUSS] When to stop supporting Python 2

[Sumanth Pasupuleti]

+1 (nb) for dropping support for python2; I agree 4.0 major release is a
good time to do this, given python2 is already EOL.

On Mon, Jan 25, 2021 at 2:00 PM Yifan Cai  wrote:

> +1 nb.
> We probably also want to set a milestone to get rid of the python2
> compatible code completely, if we are going in the direction that drops
> python2 support in 4.0 and retains the python2 compatible code. In 4.x or
> 5.0?
>
> On Mon, Jan 25, 2021 at 9:24 AM Ekaterina Dimitrova  >
> wrote:
>
> > I support the idea,  we are not removing python2-compatible code
> > +1
> >
> > On Fri, 22 Jan 2021 at 15:14, Adam Holmberg 
> > wrote:
> >
> > > As you may recall, CASSANDRA-10190 [1] introduced Python 3 support for
> > > cqlsh. This change will be landing in 4.0. In the course of development
> > and
> > > discussion spanning years, it was decided to retain support for Python
> 2.
> > > In the meantime, Python 2 sunsetted (a year ago [2]). I hadn't seen a
> > > discussion about whether we intend to carry on support for Python 2, so
> > I'm
> > > raising one here.
> > >
> > > 4.0 is a major release and we have an opportunity to drop support at
> this
> > > milestone. It has been mentioned that it will not be acceptable to do
> in
> > a
> > > minor or patch release, so if it's not done for 4.0, we will need to
> wait
> > > for the next major. I do understand that many in the project would like
> > > majors on a more frequent interval post-4.0, but at this time we don't
> > know
> > > when that will be.
> > >
> > > I advocate for dropping support ASAP. I expect that users should not be
> > > inconvenienced by this -- I am not aware of a major distro that has not
> > had
> > > python3 for years. Dropping python2 support does not mean that we would
> > do
> > > work to rip out python2-compatible code, just that we wouldn't
> advertise
> > > support and any package requirements would be adjusted. We benefit by
> > > removing the need to test multiple runtimes, and we wouldn't be
> concerned
> > > with fixing python2-specific issues that may arise on the EOL runtime
> > [3].
> > >
> > > I look forward to the discussion.
> > >
> > > --
> > > Adam Holmberg
> > > e. adam.holmb...@datastax.com
> > > w. www.datastax.com
> > >
> > > [1] https://issues.apache.org/jira/browse/CASSANDRA-10190
> > > [2] https://www.python.org/doc/sunset-python-2/
> > > [3] https://issues.apache.org/jira/browse/CASSANDRA-16400
> > >
> >
>