Re: [VOTE] CEP-8 Datastax Drivers Donation

[Adam Holmberg]

+1

(long time coming!)

On Wed, Jun 14, 2023 at 3:51 AM Jorge Bay Gondra 
wrote:

> +1 nb
>
> On Wed, Jun 14, 2023 at 9:13 AM Sam Tunnicliffe  wrote:
>
>> +1
>>
>> On 13 Jun 2023, at 15:14, Jeremy Hanna 
>> wrote:
>>
>> Calling for a vote on CEP-8 [1].
>>
>> To clarify the intent, as Benjamin said in the discussion thread [2], the
>> goal of this vote is simply to ensure that the community is in favor of
>> the donation. Nothing more.
>> The plan is to introduce the drivers, one by one. Each driver donation
>> will need to be accepted first by the PMC members, as it is the case for
>> any donation. Therefore the PMC should have full control on the pace at
>> which new drivers are accepted.
>>
>> If this vote passes, we can start this process for the Java driver under
>> the direction of the PMC.
>>
>> Jeremy
>>
>> 1.
>> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-8%3A+Datastax+Drivers+Donation
>> 2. https://lists.apache.org/thread/opt630do09phh7hlt28odztxdv6g58dp
>>
>>
>>

DataStax Driver Donation to Apache Cassandra Project

[Adam Holmberg]

The developers who maintain the DataStax drivers would like to start a
conversation about donating these drivers to the Apache Cassandra project.
Since we're actively working on the C* 4.0 support and integration in the
drivers right now, we don't plan on executing on this until after C* 4.0
releases in order to avoid delaying the release. In the meantime we wanted
to open the discussion so that we can all determine what we think best
suits the project going forward.

There are a number of details we would like to discuss as a project
community. Naming a few to get the discussion going:

- Is there interest from the project community to take ownership of the
(currently) DataStax drivers?
- Which drivers should be taken into project stewardship?
-- The project currently bundles Java and Python; there are five others:
C#, Node.js, C++, PHP and Ruby
- Which major branch of the Java driver should be chosen for development?
-- Server currently uses Java driver 3.x but the latest is 4.x
- Who will be the committers that maintain these drivers? Should we
nominate new committers (contributors on the current drivers code-bases) so
they can keep maintaining them with minimal disruption to the project as a
whole?
- What should the new artifacts be named in package indices (coordinates
and artifact names)?
- How will we run CI for these contributions?
- Do we do in-tree? Sub-projects?

There will surely be even more to figure out as we go. We look forward to
discussing this with everyone.

Kind regards,
The DS Drivers Team

Re: DataStax Driver Donation to Apache Cassandra Project

[Adam Holmberg]

g a zookeeper client donation from
> Netflix
> >that came in as a top level project. From the peanut gallery, it
> seems like
> >that has been less than ideal a couple of times in the past
> coordinating
> >releases, trademarks and such with separate project management.
> >
> >
> >
> >
> > -
> > 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
>
>

-- 
Adam Holmberg
e. adam.holmb...@datastax.com
w. www.datastax.com

Re: Committing `CASSANDRA-13701 Lower default num_tokens` and the dtest slowdown…

[Adam Holmberg]

After discussing with a few stakeholders it sounds like folks agree that
optimizing dtest speed is a worthy endeavor. What is less clear are
concrete things that should be done. Since a brainstorming session failed
to materialize on CASSANDRA-13701, we thought it would make sense to start
with an open analysis.

A ticket[1] has been created for analysis and further follow-up. We welcome
any concrete ideas people already have in mind.

Kind regards,
Adam Holmberg

[1] https://issues.apache.org/jira/browse/CASSANDRA-16079

On Mon, Aug 24, 2020 at 12:17 PM Mick Semb Wever  wrote:

>  I believe the speed of our CI runs
> > is of common interest. What do you think? Does this sound feasible? Who
> is
> > in?*
> >
>
>
> I agree. I'm in. I have some ideas to add to the mix. Thanks Ekaterina.
>


-- 
Adam Holmberg
e. adam.holmb...@datastax.com
w. www.datastax.com

Cassandra 4.0 Status 2020-11-16

[Adam Holmberg]

Good day everyone. I’m here with a 4.0 status email. We’ve been having
these in fits and starts, but after discussing in a couple fora, we’re
going to start them again in the interest of providing a bit of a pulse to
this release.

Jira board with 4.0 scope:

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

High level numbers by release phase:

Alpha: 2 (-0 from last update); 2 in-flight; no movement on board but there
has been work on their dependencies

Beta: 53 (-8); 32 in-flight

RC: 26 (+6);

Revising some high level metrics on the release:
Total tickets in 4.0: 1390 (+49)

Remaining tickets represent 5.5% of total scope (-0.4)

Created vs. resolved continues to trend positively:

https://issues.apache.org/jira/secure/ConfigureReport.jspa?projectOrFilterId=filter-12347782&periodName=daily&daysprevious=45&cumulative=true&versionLabels=major&selectedProjectId=12310865&reportKey=com.atlassian.jira.jira-core-reports-plugin%3Acreatedvsresolved-report&atl_token=A5KQ-2QAV-T4JA-FDED_a3bea645259beee42ed00c68f87626d5972705c4_lin&Next=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&jql=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:

4 Beta and 2 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&quickFilter=1661&quickFilter=1659

*No assignee:
9 Beta and 5 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&quickFilter=1661&quickFilter=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&quickFilter=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, 11 beta, 7 GA

https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=355&quickFilter=1661&quickFilter=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.


-Adam Holmberg

Re: cassandra--dtest: module 'pytest' has no attribute 'config'

[Adam Holmberg]

Hello. It looks like your environment might be using a newer version of
pytest than is supported by these tests.
https://docs.pytest.org/en/latest/deprecations.html#pytest-config-global

Note that the requirements file specifies a fixed, older version of pytest:
https://github.com/apache/cassandra-dtest/blob/192b70607a0c4a96f524bd5dc0c19c3a28f938f0/requirements.txt#L9

On Fri, Dec 4, 2020 at 5:32 AM Ahmed Eljami  wrote:

> Hi folks,
>
> I'm trying to run dtest on local and getting the following error (I
> configure it to run the only refresh_test.py test):
>
> $ pytest --cassandra-dir=/home/aeljami/workspace/git/cstar/cassandra
>
> == test session
> > starts ==
> > platform linux -- Python 3.6.9, pytest-6.1.2, py-1.9.0, pluggy-0.13.1
> > rootdir: /home/aeljami/workspace/git/cassandra-dtest, configfile:
> > pytest.ini
> > plugins: flaky-3.7.0
> > collected 1 item
> >
> > refresh_test.py E
> > [100%]
> >
> >  ERRORS
> > =
> > __ ERROR at setup of
> > TestRefresh.test_refresh_deadlock_startup
> > __
> >
> > request =  > test_refresh_deadlock_startup>>
> >
> > @pytest.fixture(scope="function", autouse=True)
> > def fixture_logging_setup(request):
> > # set the root logger level to whatever the user asked for
> > # all new loggers created will use the root logger as a template
> > # essentially making this the "default" active log level
> > log_level = logging.INFO
> > try:
> > # first see if logging level overridden by user as command
> > line argument
> > >   log_level_from_option =
> pytest.config.getoption("--log-level")
> > E   AttributeError: module 'pytest' has no attribute 'config'
> >
> > conftest.py:135: AttributeError
> >
>
>  short test summary
> > info 
> > ERROR refresh_test.py::TestRefresh::test_refresh_deadlock_startup -
> > AttributeError: module 'pytest' has no attribute 'config'
> >
>
> $ cat pytest.ini
>
> [pytest]
> > cassandra_dir= /home/aeljami/workspace/git/cstar/cassandra
> > python_files = refresh_test.py
> > junit_suite_name = Cassandra dtests
> > log_print = True
> > log_level = INFO
> > log_format = %(asctime)s,%(msecs)d %(name)s %(levelname)s %(message)s
> > timeout = 900
> >
>
>  Any idea please ?
>
> Thanks
>


-- 
Adam Holmberg
e. adam.holmb...@datastax.com
w. www.datastax.com

Re: Cassandra 4.0 Status 2020-12-07

[Adam Holmberg]

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
>
>

-- 
Adam Holmberg
e. adam.holmb...@datastax.com
w. www.datastax.com

Cassandra 4.0 Status 2020-12-14

[Adam Holmberg]

Good day everyone. This is a 4.0 status email. One week since the last
update.

Jira board with 4.0 scope:

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

High level numbers by release phase:

Alpha: 1 (-0 from last update); It’s close, with Mick nearing end of review
on the prerequisite test changes

Beta: 64 (+9); 38 in-flight

RC: 21 (+1);

Revising some high level metrics on the release:
Total tickets in 4.0: 1505
Remaining tickets represent 5.6% of total scope (increasing)

Created vs. resolved did NOT trend positively:

https://issues.apache.org/jira/secure/ConfigureReport.jspa?projectOrFilterId=filter-12347782&periodName=daily&daysprevious=45&cumulative=true&versionLabels=major&selectedProjectId=12310865&reportKey=com.atlassian.jira.jira-core-reports-plugin%3Acreatedvsresolved-report&atl_token=A5KQ-2QAV-T4JA-FDED_a3bea645259beee42ed00c68f87626d5972705c4_lin&Next=Next

Tickets increased this week, mostly due to broken tests being decomposed
into individual tickets, There have also been a number of things stalled in
review.


Where you can help:

* One thing I wanted to call attention to are the numerous tickets sitting
in review which are apparently approved. We will look forward to getting
those in as time allows to avoid having to scan past.

* 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&jql=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&quickFilter=1661&quickFilter=1659

*No assignee:
14 Beta and 4 RC issues

Lots of new broken test tickets. 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&quickFilter=1661&quickFilter=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&quickFilter=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, 18 beta, 14 GA

https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=355&quickFilter=1661&quickFilter=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 hard work on the project.

-Adam Holmberg

Cassandra 4.0 Status 2020-01-19

[Adam Holmberg]

Greetings. With the quality test epic discussion ongoing in another thread,
I have been inspired to freshen up some queries and write the first 4.0
status of the new year. It has been five weeks since the last update. Even
with the holidays in the interim, we’re seeing some good movement this
interval.

Jira board with 4.0 scope:

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

High level numbers by release phase:

Alpha: 0! (-1 from last update)

Beta: 22 (-42); 17 in-flight; Pursuant to a mailing list discussion, some
non-blocking tickets were moved to RC. Aside from that, a significant
number of in-flight beta tickets made it through review in recent weeks.
There are still a fair number in that phase. Big thanks to people working
through those.

RC: 37 (+16); (see above explanation)

Top-level metrics:
Total tickets in 4.0: 1511
Remaining tickets represent 3.9% of total scope

Created vs. resolved trended sharply positive:
https://issues.apache.org/jira/secure/ConfigureReport.jspa?projectOrFilterId=filter-12347782&periodName=daily&daysprevious=45&cumulative=true&versionLabels=major&selectedProjectId=12310865&reportKey=com.atlassian.jira.jira-core-reports-plugin%3Acreatedvsresolved-report&atl_token=A5KQ-2QAV-T4JA-FDED_a3bea645259beee42ed00c68f87626d5972705c4_lin&Next=Next

Where you can help:

* There are deliciously few tickets left in beta fix versions. Any work
people can do on remaining blockers will accelerate the project toward RC.
There are a handful of bugs, and several PRs in need of review or merge.

* Ahead of the rest of our regular filter links, I’ll repeat the list of
flaky tests Scott called out in the other thread:
– CASSANDRA-16236: Fix flaky testTrackMaxDeletionTime
– CASSANDRA-16238: Fix flaky test
test_insert_data_during_replace_same_address -
replace_address_test.TestReplaceAddress
– CASSANDRA-16239: Fix flaky test
org.apache.cassandra.distributed.test.NetstatsRepairStreamingTest
testWithCompressionDisabled
– CASSANDRA-16317: Fix flaky test incompleteCommit -
org.apache.cassandra.distributed.test.CASTest
– CASSANDRA-16355: Fix flaky test incompletePropose -
org.apache.cassandra.distributed.test.CASTest
– CASSANDRA-16382: Fix flaky
LongSharedExecutorPoolTest.testPromptnessOfExecution
– CASSANDRA-16358: Minor Flakiness in
ProxyHandlerConnectionsTest#testExpireSomeFromBatch
– CASSANDRA-16229: Flaky jvm-dtest:
org.apache.cassandra.distributed.test.ring.NodeNotInRingTest.nodeNotInRingTest
– CASSANDRA-16061:
transient_replication_ring_test.py::TestTransientReplicationRing::test_move_forwards_and_cleanup

… and now for the boilerplate board filter reminders:

* 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&jql=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:
2 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&quickFilter=1661&quickFilter=1659

*No assignee:
2 Beta and 7 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&quickFilter=1661&quickFilter=1658

*Test analysis and shepherding. There is some more detailed discussion
about these in the other recent thread.
https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=355&quickFilter=1939

*Tickets stalled for a week:
6 beta, 19 GA
https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=355&quickFilter=1661&quickFilter=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 hard work on the project.

-- 
Adam Holmberg
e. adam.holmb...@datastax.com
w. www.datastax.com

[DISCUSS] When to stop supporting Python 2

[Adam Holmberg]

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

[Adam Holmberg]

>
> Does anybody know what are the practicalities/hurdles
> that users can face when upgrading and what is the expected cost of keeping
> support for 2.7 until the next major?
>

Given that the code supports both, the only barrier to the user is "does my
distro have python3 (most likely), or would I have to install it?".

The cost of keeping support is a small amount of drag as we consider fixing
bugs and maintaining compatibility. It's not huge, but I don't see a lot of
reasons to incur it.

I want to emphasize here: to my way of thinking, "dropping support" at this
juncture is just a matter of documenting it, and maybe introducing a
warning. We don't need to *remove* support for python2. It will continue to
work as-is. This would just guide us in deciding whether to work on flaws
that are python2-specific, and whether new things are developed with
backwards compatibility as a forcing concern.

I'll have to catch up on the other ticket and see what bearing it has on
this discussion.


On Tue, Jan 26, 2021 at 1:46 AM Sumanth Pasupuleti <
sumanth.pasupuleti...@gmail.com> wrote:

> +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 <
> e.dimitr...@gmail.com
> > >
> > wrote:
> >
> > > I support the idea,  we are not removing python2-compatible code
> > > +1
> > >
> > > On Fri, 22 Jan 2021 at 15:14, Adam Holmberg <
> adam.holmb...@datastax.com>
> > > 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://urldefense.proofpoint.com/v2/url?u=https-3A__www.python.org_doc_sunset-2Dpython-2D2_&d=DwIBaQ&c=adz96Xi0w1RHqtPMowiL2g&r=GgOKQUoTLCKbKh1M_uCZ-t7CW3HHZHE_I4OFzjDOiIs&m=PHNtl_WeGlGcuZQ1iwiajdr1eBZpuu1uxx8Ty-LCtiw&s=dDf0vhcr06PYYRjqcO9iwAWvN109cwYQNF6k9odIMIs&e=
> > > > [3] https://issues.apache.org/jira/browse/CASSANDRA-16400
> > > >
> > >
> >
>


-- 
Adam Holmberg
e. adam.holmb...@datastax.com
w. www.datastax.com

Cassandra 4.0 Status 2021-01-27

[Adam Holmberg]

Greetings. Here’s a quick look at Cassandra 4.0 release status for the
week. Eight days since the last report.

Jira board with 4.0 scope:

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

High level numbers by release phase:

Beta: 15 (-7); 10 in-flight; A good number of tickets were closed in this
interval, and there are not many left in this scope. So close!

RC: 38 (+1); 22 in-flight;  Lots of good work happening here

Top-level metrics:

Total tickets in 4.0: 1518

Remaining tickets represent 3.5% of total scope

Created vs. resolved continued in a positive trend:

https://issues.apache.org/jira/secure/ConfigureReport.jspa?projectOrFilterId=filter-12347782&periodName=daily&daysprevious=45&cumulative=true&versionLabels=major&selectedProjectId=12310865&reportKey=com.atlassian.jira.jira-core-reports-plugin%3Acreatedvsresolved-report&atl_token=A5KQ-2QAV-T4JA-FDED_a3bea645259beee42ed00c68f87626d5972705c4_lin&Next=Next

Where you can help:

* We’re within line-of-sight to closing out beta scope. Any work people can
do on remaining blockers will accelerate the project toward RC. There are a
handful of bugs, and PRs in need of review or merge.

* 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.
In addition it is helpful to move things you’re on to “In Progress” to
avoid folks having to check in on assigned tickets in “TO DO”.

Here’s a query to check your current open+assigned items:

https://issues.apache.org/jira/issues/?filter=12348585&jql=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:

Single RC issue awaiting review without reviewers:
https://issues.apache.org/jira/browse/CASSANDRA-16245

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

*No assignee:

2 Beta and 5 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&quickFilter=1661&quickFilter=1658

*Tickets stalled for a week:

3 beta, 23 GA

https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=355&quickFilter=1661&quickFilter=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 hard work on the project.


-- 
Adam Holmberg
e. adam.holmb...@datastax.com
w. www.datastax.com

Re: [DISCUSS] When to stop supporting Python 2

[Adam Holmberg]

Thanks for the discussion and input. It seems like this thread has run its
course, so I'm hoping to bring it to a close with the following:

for 4.0:
- Update documentation removing any claim of support for Python2 (but do
not actually break).
Introduce warning when running in Python 2.7.
I created https://issues.apache.org/jira/browse/CASSANDRA-16414

decoupled:
- Backport Python 3 support at least to 3.11. I noticed there was already a
ticket:
https://issues.apache.org/jira/browse/CASSANDRA-16403
This makes sense since I believe the intent is to support 3.11 for a good
while longer. Going back to 3.0 could be tackled as part of that ticket, or
possibly abandoned if we decide the length of time left supporting that
line does not warrant it (or as Sumanth points out, we don't want big
changes there).

- Make packaging and internal tooling work with Python3. This is
multifaceted. There was already this:
https://issues.apache.org/jira/browse/CASSANDRA-16396
And I expect others will crop up as our desire to get off Python2
increases, but I don't know if there is a forcing function for the project
right now.


On Thu, Jan 28, 2021 at 10:44 AM Sumanth Pasupuleti <
sumanth.pasupuleti...@gmail.com> wrote:

> From the "Supported upgrade path for 4.0" discussion, it seems like there
> was consensus around supporting the "3.0 -> 4.0" upgrade path as well (in
> addition to 3.11 -> 4.0), so we may need to add python3 support for 3.0 as
> well?
>
> Internally. we had a need to make 3.0 cqlsh python3 compatible, and I ended
> up backporting trunk pylib, cqlsh, cqlsh.py for python3 support and
> reverted https://issues.apache.org/jira/browse/CASSANDRA-14825 (this
> backport is currently being tested). Haven't assessed the impact on dtest
> environment yet. This approach was much less effort vs cherry-picking
> individual changes, but involves probably equal or more testing effort. If
> we decide to add python3 support for 3.0, I am happy to contribute this
> once we have enough confidence from testing (but unsure if we have
> the appetite for this big a change in 3.0).
>
>
>
> On Thu, Jan 28, 2021 at 3:01 AM Benjamin Lerer <
> benjamin.le...@datastax.com>
> wrote:
>
> > Considering the issue with pip. I agree that we should remove support for
> > 3.0 and ensure that python 3 is supported by 3.11.
> >
> > On Wed, Jan 27, 2021 at 8:18 PM Jonathan Ellis 
> wrote:
> >
> > > Python 2 was EOLed over a year ago.  I think it's fine to (1) require
> > > python 3 to run cqlsh and (2) remove code that supports python 2
> whenever
> > > it's convenient.
> > >
> > > Angelo has the right idea that rather than trying to finesse a
> > deprecation
> > > cycle into 4.0 at this late date, a better migration path can be
> provided
> > > by backporting python3 support to 3.11.
> > >
> > > On Wed, Jan 27, 2021 at 12:36 PM Brandon Williams 
> > > wrote:
> > >
> > > > On Wed, Jan 27, 2021 at 12:09 PM Adam Holmberg
> > > >  wrote:
> > > > > I want to emphasize here: to my way of thinking, "dropping support"
> > at
> > > > this
> > > > > juncture is just a matter of documenting it, and maybe introducing
> a
> > > > > warning. We don't need to *remove* support for python2. It will
> > > continue
> > > > to
> > > > > work as-is. This would just guide us in deciding whether to work on
> > > flaws
> > > > > that are python2-specific, and whether new things are developed
> with
> > > > > backwards compatibility as a forcing concern.
> > > >
> > > > Actually, I think we have to go a little bit further, and at least as
> > > > far as packaging is concerned, remove support for python2.  Recently
> > > > pip updated to 21.0 and removed python2 support, which broke any
> > > > builds that built artifacts requiring pip.  We now pin pip:
> > > >
> > > >
> > >
> >
> https://github.com/apache/cassandra-builds/commit/54c45a9bcf9b36a3f78b7d773eaf1067483b49b8
> > > > to get around this, but highlights that we too need to move away from
> > > > anything using python2.  So while we would not modify code to
> *remove*
> > > > python2 support, you would have to invoke python2 on the code in your
> > > > own way, since the packages would depend on python3.
> > > >
> > > > -
> > > > 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
> > >
> >
>


-- 
Adam Holmberg
e. adam.holmb...@datastax.com
w. www.datastax.com

Cassandra 4.0 Status 2021-02-03

[Adam Holmberg]

Greetings. Here’s a quick look at Cassandra 4.0 release status for the week.

Jira board with 4.0 scope:

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

High level numbers by release phase:

Beta: 13 (-2); 11 in-flight; Nothing much to comment on here. Just that
it's close, so let’s keep hammering on these, and refer to the stalled
ticket filter below.

RC: 37 (-1); 20 in-flight; Tickets stalled 7d+ is at an all-time high. See
filter below.

Top-level metrics:

Total tickets in 4.0: 1525 (+7)

Remaining tickets represent 3.3% of total scope

Created vs. resolved continued a positive trend, although not quite as
magnificent as the past couple weeks:

https://issues.apache.org/jira/secure/ConfigureReport.jspa?projectOrFilterId=filter-12347782&periodName=daily&daysprevious=45&cumulative=true&versionLabels=major&selectedProjectId=12310865&reportKey=com.atlassian.jira.jira-core-reports-plugin%3Acreatedvsresolved-report&atl_token=A5KQ-2QAV-T4JA-FDED_a3bea645259beee42ed00c68f87626d5972705c4_lin&Next=Next

Where you can help:

* We’re within line-of-sight to closing out beta scope. Any work people can
do on remaining blockers will accelerate the project toward RC. There are a
handful of bugs, and several PRs in need of review or merge.

* 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.
In addition it is helpful to move things you’re on to “In Progress” to
avoid folks having to check in on assigned tickets in “TO DO”.

Here’s a query to check your current open+assigned items:

https://issues.apache.org/jira/issues/?filter=12348585&jql=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:

Repair test ticket remains up for review with no reviewer:
https://issues.apache.org/jira/browse/CASSANDRA-16245
Debian packaging for Python3 is newly up for review:
https://issues.apache.org/jira/browse/CASSANDRA-16396

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

*No assignee:

0 Beta! and 7 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&quickFilter=1661&quickFilter=1658

*Tickets stalled for a week:

2 beta, 27 GA

https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=355&quickFilter=1661&quickFilter=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 hard work on the project.


-- 
Adam Holmberg
e. adam.holmb...@datastax.com
w. www.datastax.com

Cassandra 4.0 Status 2021-02-11

[Adam Holmberg]

Greetings. Here’s a quick look at Cassandra 4.0 release status for the week.

Jira board with 4.0 scope:

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

High level numbers by release phase:

Beta: 15 (+2); ALL in-flight; Handful of new issues but no apparent show
stoppers. Still close, and nothing left that is not started. Usual reminder
to refer to the stalled ticket filter below.

RC: 38 (+1); 20 in-flight; Tickets stalled 7d+ remains at an all-time high.
See filter below.

Top-level metrics:

Total tickets in 4.0: 1541 (+16)

Remaining tickets represent 3.4% of total scope

Created vs. resolved did not trend positively on this interval

https://issues.apache.org/jira/secure/ConfigureReport.jspa?projectOrFilterId=project-12310865&periodName=daily&daysprevious=8&cumulative=true&versionLabels=major&selectedProjectId=12310865&reportKey=com.atlassian.jira.jira-core-reports-plugin%3Acreatedvsresolved-report&atl_token=A5KQ-2QAV-T4JA-FDED_b579df86215ae5de4a07e55cc0198144e0b407c8_lin&Next=Next

Where you can help:

* We’re within line-of-sight to closing out beta scope. Any work people can
do on remaining blockers will accelerate the project toward RC. There are a
handful of bugs, and several PRs in need of review or merge.

* 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.
In addition it is helpful to move things you’re on to “In Progress” to
avoid folks having to check in on assigned tickets in “TO DO”.

Here’s a query to check your current open+assigned items:

https://issues.apache.org/jira/issues/?filter=12348585&jql=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:

2 beta, 2 GA tickets are up for review with no reviewer

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

*No assignee:

0 Beta! and 5 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&quickFilter=1661&quickFilter=1658

*Tickets stalled for a week:

2 beta, 27 GA

https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=355&quickFilter=1661&quickFilter=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 hard work on the project.


-- 
Adam Holmberg
e. adam.holmb...@datastax.com
w. www.datastax.com

Cassandra 4.0 Status 2021-02-18

[Adam Holmberg]

Greetings. Here’s a quick look at Cassandra 4.0 release status for the week.

Jira board with 4.0 scope:

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

High level numbers by release phase:

Beta: 11 (-4); All but one in-flight; We had a few flaky tests trickle in,
but folks are making good progress moving things through. Usual reminder to
refer to the stalled ticket filter below.

RC: 38 (+0); 21 in-flight; Tickets stalled 7d+ is at an all-time high. See
filter below.

Top-level metrics:

Total tickets in 4.0: 1556 (+15)

Remaining tickets represent 2.5% of total scope

Created vs. resolved in-scope trended positively on this interval.

Where you can help:

* We’re within line-of-sight to closing out beta scope. Any work people can
do on remaining blockers will accelerate the project toward RC. There are a
handful of bugs, and several PRs in need of review or merge.

* 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.
In addition it is helpful to move things you’re on to “In Progress” to
avoid folks having to check in on assigned tickets in “TO DO”.

Here’s a query to check your current open+assigned items:

https://issues.apache.org/jira/issues/?filter=12348585&jql=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:

2 GA tickets are up for review with no reviewer

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

*No assignee:

1 Beta and 6 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&quickFilter=1661&quickFilter=1658

*Tickets stalled for a week:

4 beta, 30 GA

https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=355&quickFilter=1661&quickFilter=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 hard work on the project.


-- 
Adam Holmberg
e. adam.holmb...@datastax.com
w. www.datastax.com

Cassandra 4.0 Status 2021-02-25

[Adam Holmberg]

Greetings. Here’s a quick look at Cassandra 4.0 release status for the
week. We've had lots of exciting progress on beta scope! Seven days since
last update.

Jira board with 4.0 scope:

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

High level numbers by release phase:

Beta: 6 (-5); All in-flight;.

RC: 35 (-3);18 in-flight; Tickets stalled 7d+ is at an all-time high.
Presumably that’s because folks are focused on retiring beta scope.

Top-level metrics:

Total tickets in 4.0: 1563 (+7)

Remaining tickets represent 2.6% of total scope

Created vs. resolved trended sharply positive on this interval.

Where you can help:

* We’re within line-of-sight to closing out beta scope. Any work people can
do on remaining blockers will accelerate the project toward RC.

* 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.
In addition it is helpful to move things you’re on to “In Progress” to
avoid folks having to check in on assigned tickets in “TO DO”.

Here’s a query to check your current open+assigned items:

https://issues.apache.org/jira/issues/?filter=12348585&jql=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:

(The same) 2 GA tickets are up for review with no reviewer

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

*No assignee:

5 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&quickFilter=1661&quickFilter=1658

*Tickets stalled for a week:

32 GA

https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=355&quickFilter=1661&quickFilter=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 hard work on the project.


-- 
Adam Holmberg
e. adam.holmb...@datastax.com
w. www.datastax.com

Cassandra 4.0 Status 2021-03-04

[Adam Holmberg]

Greetings. Here’s your look at Cassandra 4.0 release status for the week.
Seven days since last update.

Jira board with 4.0 scope:

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

High level numbers by release phase:

Beta: 6 (-0); All in-flight; several got resolved, but several new tickets
entered scope.

RC: 36 (+1);18 in-flight; Tickets stalled 7d+ is at an all-time high.
Presumably that’s because folks are focused on retiring beta scope.

Top-level metrics:

Total tickets in 4.0: 1576 (+13)

Remaining tickets represent 2.7% of total scope

Created vs. resolved trended marginally positive on this interval.

Where you can help:

* There’s always more to do investigating and stabilizing tests. Help on
that is appreciated.

* We’re within line-of-sight to closing out beta scope. Any work people can
do on remaining blockers will accelerate the project toward RC.

* 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.
In addition it is helpful to move things you’re on to “In Progress” to
avoid folks having to check in on assigned tickets in “TO DO”.

Here’s a query to check your current open+assigned items:

https://issues.apache.org/jira/issues/?filter=12348585&jql=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, 1 RC ticket up for review with no reviewer

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

*No assignee:

(same) 5 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&quickFilter=1661&quickFilter=1658

*Tickets stalled for a week:

27 GA tickets stalled. The upward trend has subsided!

https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=355&quickFilter=1661&quickFilter=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 hard work on the project.


-- 
Adam Holmberg
e. adam.holmb...@datastax.com
w. www.datastax.com

Cassandra 4.0 Status 2021-03-11

[Adam Holmberg]

Greetings. Here’s your look at Cassandra 4.0 release status for the week.
Seven days since last update.

Jira board with 4.0 scope:

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

High level numbers by release phase:

Beta: 1(!) (-5);

RC: 37 (+1); 23 in-flight;

Top-level metrics:

Total tickets in 4.0: 1592 (+12)

Remaining tickets represent 2.4% of total scope

Created vs. resolved trended solidly positive on this interval.

Where you can help:

* There’s always more to do investigating and stabilizing tests. Help on
that is appreciated.

* We’re within line-of-sight to closing out beta scope. Any work people can
do on remaining blocker will accelerate the project toward RC.

* 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.
In addition it is helpful to move things you’re on to “In Progress” to
avoid folks having to check in on assigned tickets in “TO DO”.

Here’s a query to check your current open+assigned items:

https://issues.apache.org/jira/issues/?filter=12348585&jql=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:

2 RC ticket up for review with no reviewer

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

*No assignee:

(same) 5 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&quickFilter=1661&quickFilter=1658

*Tickets stalled for a week:

22 GA tickets stalled. The stall trend here has reversed as we’ve bottomed
out on beta scope.

https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=355&quickFilter=1661&quickFilter=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 hard work on the project.

-- 
Adam Holmberg
e. adam.holmb...@datastax.com
w. www.datastax.com

Cassandra 4.0 Status 2021-03-18

[Adam Holmberg]

Ahoy. Here’s a look at Cassandra 4.0 release status for the week. Seven
days since last update.

Jira board with 4.0 scope:

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

High level numbers by release phase:

Beta: 2 (+1); two recently-introduced flaws arose; Both in review now, one
with +1 and good CI

RC: 38 (+1); 28 in-flight; lots of good activity here -- half of the
previously stalled tickets have had activity in the last week.

Top-level metrics:

Total tickets in 4.0: 1608 (+16)

Remaining tickets represent 2.5% of total scope

Created vs. resolved trended solidly positive on this interval.

Where you can help:

* We’re within line-of-sight to closing out beta scope. Any reviews on the
patches in-flight will nudge the project toward RC.

* There’s always more to do investigating and stabilizing tests. Help on
that is appreciated.


* Needs Reviewer:

3 RC tickets up for review with no reviewer

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

* No assignee:

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&quickFilter=1661&quickFilter=1658

* Tickets stalled for a week:

11 GA tickets. The stall trend is in full reverse! Half of the stalled
tickets have moved since last week.

https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=355&quickFilter=1661&quickFilter=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 hard work on the project.


-- 
Adam Holmberg
e. adam.holmb...@datastax.com
w. www.datastax.com

Cassandra Wiki Edit Permissions for user AdamHolmberg

[Adam Holmberg]

I'm seeking wiki edit permissions for my user on
https://wiki.apache.org/cassandra/:
"AdamHolmberg"

Regards,
Adam Holmberg

Re: V5 as a protocol beta version in 3.11

[Adam Holmberg]

I agree that it is okay to leave v5 beta behind. As I recall, the point of
beta was less about trying stuff early, but more to allow early
implementation and testing of new protocol features, before the scope was
finalized. Now that v5 proper has diverged from beta it is no longer
supported. I don't see much value in back-porting, nor do I think we
should  increment versions in order to maintain compatibility with
something that was expressly beta.

I think we should disable v5 testing in 3.x branch and let the v5 spec
continue to evolve in *non-beta* status in 4.0 until it is finalized upon
release.

Adam Holmberg

On Tue, Nov 7, 2017 at 10:57 AM, J. D. Jordan 
wrote:

> Again. V5 beta in 3.11 was always meant to stop working when future things
> happened to V5 in the drivers and in C*.  I see no problem with leaving the
> beta V5, which is an opt in thing to try out, in 3.11 alone. 4.0 will have
> the full non beta V5 with extra stuff in it, and will not work with beta V5.
> Nothing uses the beta V5 by default. It is an opt in thing to be used if
> you wanted to try out stuff early.
>
> -Jeremiah
>
> > On Nov 7, 2017, at 11:39 AM, Oleksandr Petrov <
> oleksandr.pet...@gmail.com> wrote:
> >
> > This is an option, you're right. In this case v5 will have just one
> > feature, however, and the only feature (Duration type) should work with
> via
> > CustomTypes through v4.
> >
> > Looks like the Jira numbers were off, so let me do it again:
> >
> > In 3.11 we have:
> >  * CASSANDRA-12838 - Extend native protocol flags and add supported
> > versions to the SUPPORTED response
> >  * CASSANDRA-12142 - Add "beta" version native protocol flag
> >  * CASSANDRA-12850 - Add the duration type to the protocol V5 <-- (this
> > one should also work with v4)
> >
> > In 4.0 we have
> >  * CASSANDRA-10786 - Include hash of result set metadata in prepared
> > statement id
> >
> > And the options:
> >
> >  * (1) remove v5 from 3.11 by reverting #12838 and #12142
> >  * (2) support v5 in 3.11 forever and backport #10786
> >  * (3) bump 4.0 version to v6 and make sure that #10786 is v6
> >
> > Question with (1) is mostly whether or not we would like to cut another
> > version release because of (in essence) #12838 only, since #12142 is not
> > relevant in the context and #12850 will still work.
> >
> >
> >
> >> On Tue, Nov 7, 2017 at 4:19 PM Jonathan Haddad 
> wrote:
> >>
> >> The other option, to avoid having two different v5 implementations, is
> to
> >> bump 4.0’s protocol version to 6.
> >> On Tue, Nov 7, 2017 at 6:48 AM Jeremiah D Jordan <
> >> jeremiah.jor...@gmail.com>
> >> wrote:
> >>
> >>> My 2 cents.  When we added V5 to 3.x wasn’t it added as a beta protocol
> >>> for tick/tock stuff and known that when a new version came out it would
> >>> most possibly break the older releases V5 beta stuff? Or at the very
> >> least
> >>> add new things to V5.  So I see no reason to need to add more new
> >> features
> >>> to 3.11 v5.
> >>>
> >>> -Jeremiah
> >>>
> >>>> On Nov 7, 2017, at 9:41 AM, Oleksandr Petrov <
> >> oleksandr.pet...@gmail.com>
> >>> wrote:
> >>>>
> >>>> Hi everyone,
> >>>>
> >>>> Currently, 3.11 supports V5 as a protocol version. However, all new
> >>>> features are now going to 4.0, which is going to be a new feature
> >>> release.
> >>>>
> >>>> Right now we have two v5 features:
> >>>>
> >>>>  - CASSANDRA-10786 <
> >>> https://issues.apache.org/jira/browse/CASSANDRA-10786>
> >>>>  - CASSANDRA-12838 <
> >>> https://issues.apache.org/jira/browse/CASSANDRA-12838>
> >>>>
> >>>>
> >>>> #12838 is adding duration type, which is a nice addition. #10786 is
> >> also
> >>>> useful, but is more of an edge cases for users with huge clusters
> >> and/or
> >>>> frequent schema changes.
> >>>>
> >>>> If we leave v5 in 3.11, we'll have to always backport all v5 features
> >> to
> >>>> 3.11. This is something that hasn't been done in #10786. So the
> >> question
> >>>> is: are we ready to commit and support v5 in 3.11 "forever", or should
> >> we
> >>>> stop until it went too far and remove v5 from 3.11 since it's still in
> >>> beta
> >>>> there.
> >>>>
> >>>> Looking forward to hear your opinion,
> >>>>
> >>>>
> >>>> --
> >>>> Alex Petrov
> >>>
> >>>
> >>> -
> >>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> >>> For additional commands, e-mail: dev-h...@cassandra.apache.org
> >>>
> >>>
> >>
> > --
> > Alex Petrov
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>

JIRA Label for Client-Impacting Changes/Decisions

[Adam Holmberg]

As a Cassandra driver developer, I'm looking for a good way to keep track
of client-impacting changes and decisions in Cassandra. I'm aware of super
tasks like CASSANDRA-8043
 (native v4), and
others (schema migration
, schema modernization
) via ad hoc
communication.

Beyond feature changes, there is a class of decisions that might not change
existing functionality, but imposes certain limitations on clients using
new features. As an example, this week I learned of a decision to serialize
collections in v3 encoding, regardless of protocol:
https://issues.apache.org/jira/browse/CASSANDRA-8438

Presently, there is no aggregate view of new features, changes, and
decisions on issues that might impact client integration.

In the discussion on CASSANDRA-8438 it was suggested that we might use
labels to tag issues with implications to client integrators, so I wanted
to float the idea here -- would maintainers be amenable to labeling
client-impacting issues in JIRA?


Adam

Re: JIRA Label for Client-Impacting Changes/Decisions

[Adam Holmberg]

I think the issue that brought this up was more about collection
serialization. Since collections existed before v3, it was surprising to
see outer collections serialized with one format and inner with another.

I'm not questioning that decision, nor do I want to operate in
'undocumented territory'. What I do want to do is find a good way to know
when these assumptions are made. I was hoping a label would help in being
applied across different categories of decisions that impact clients.

I didn't hear any strong opposition to trying the label. Is anyone allowed
to create them? If so, I'll start applying it to the things I know about.
Are there other issues that haven't been mentioned previously in this
thread?

Thanks,
Adam

On Tue, Dec 16, 2014 at 12:56 PM, Sylvain Lebresne 
wrote:

> We already try to use labels (though we definitively haven't always done it
> in the past): all protocolv4 stuffs should have a protocolv4 label, and I'm
> all for continuing to stick to it. I'm fine having an additional "driver
> impacting" tag for stuff that are likely to need special driver handling
> (as it's probably not limited to protocol stuffs). And I'm not strongly
> against a section in the NEWS file, though we've already have a changelog
> in the spec itself and it kinds of feels like a better place.
>
> But honestly, regarding the issue that raised this, it's not so much that
> we made a decision to do something new for the protocol v2: UDT are just
> not natively supported by the protocol v2 (for the simple reason that they
> didn't existed when the v2 was done). As far as v2 is concerned, UDT are an
> opaque "custom type". If you want to support UDT in your client, you should
> officially support v3. You're free to try to support UDT nonetheless in v2,
> and some drivers do, but you're in undocumented territory.
>
>
> On Tue, Dec 16, 2014 at 6:20 PM, Aleksey Yeschenko 
> wrote:
>
> > A label works for me.
> >
> > But we also need a separate .txt file, or a section in NEWS.txt, for
> those
> > who can’t, or don’t want to follow the JIRA. Can’t realistically expect
> > people to do that.
> >
> > --
> > AY
> >
> > On December 16, 2014 at 8:15:43 PM, Tyler Hobbs (ty...@datastax.com)
> > wrote:
> >
> > I'm personally in favor of using a label. Besides myself, Sylvain,
> > Benjamin, and Aleksey are probably the most likely to be keeping track of
> > this. Any objections or alternatives from you guys?
> >
> > On Fri, Dec 12, 2014 at 5:41 PM, Adam Holmberg <
> adam.holmb...@datastax.com
> > >
> > wrote:
> >
> > > As a Cassandra driver developer, I'm looking for a good way to keep
> track
> > > of client-impacting changes and decisions in Cassandra. I'm aware of
> > super
> > > tasks like CASSANDRA-8043
> > > <https://issues.apache.org/jira/browse/CASSANDRA-8043> (native v4),
> and
> > > others (schema migration
> > > <https://issues.apache.org/jira/browse/CASSANDRA-6038>, schema
> > > modernization
> > > <https://issues.apache.org/jira/browse/CASSANDRA-6717>) via ad hoc
> > > communication.
> > >
> > > Beyond feature changes, there is a class of decisions that might not
> > change
> > > existing functionality, but imposes certain limitations on clients
> using
> > > new features. As an example, this week I learned of a decision to
> > serialize
> > > collections in v3 encoding, regardless of protocol:
> > > https://issues.apache.org/jira/browse/CASSANDRA-8438
> > >
> > > Presently, there is no aggregate view of new features, changes, and
> > > decisions on issues that might impact client integration.
> > >
> > > In the discussion on CASSANDRA-8438 it was suggested that we might use
> > > labels to tag issues with implications to client integrators, so I
> wanted
> > > to float the idea here -- would maintainers be amenable to labeling
> > > client-impacting issues in JIRA?
> > >
> > >
> > > Adam
> > >
> >
> >
> >
> > --
> > Tyler Hobbs
> > DataStax <http://datastax.com/>
> >
>

Cassandra 4.0 Status 2021-03-25

[Adam Holmberg]

Greetings. Here’s your look at Cassandra 4.0 release status for the week --
this one with 300% more exclamation points! Seven days since last update.


Jira board with 4.0 scope:

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


High level numbers by release phase:


Beta: 0! (-2); This week the project bottomed out on known blocking flaws!
The only thing ahead of an RC resolving the remaining flaky tests, and
getting a clean CI run.

RC: 20 (-18); 14 in-flight; in addition to plenty of good progress on
tickets in scope, some of the open-ended quality tickets were discussed and
moved to post-4.0.


Top-level metrics:

Total tickets in 4.0: 1609 (+1)

Remaining tickets represent 1.2% of total scope


Created vs. resolved trended solidly positive on this interval.


Where you can help:


* We’ve bottomed out on known flaws ahead of RC. There are flaky tests
keeping us from clean CI. Any time spent Investigating and stabilizing
tests is appreciated.

*Needs Reviewer:

1 RC tickets up for review with no reviewer

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


*No assignee:

zero!

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


*Tickets stalled for a week:

5 GA tickets stalled. The stall trend continues to diminish. More than half
of the stalled tickets have moved since last week.

https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=355&quickFilter=1661&quickFilter=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 hard work on the project.

Cassandra 4.0 Status 2021-04-01

[Adam Holmberg]

Greetings. Here’s your look at Cassandra 4.0 release status for the week.
Seven days since last update.

To begin by summarizing a few things from elsewhere on the list this week:
After observing clean CI last week, an RC was cut and a vote started on
Monday. Thursday saw the vote cut short as an issue raised in RC testing
was confirmed as a blocking issue. Also during RC evaluation some concerns
were raised about the contents of the source distribution. The work
resolving that got underway and is ready to commit.
https://issues.apache.org/jira/browse/CASSANDRA-16391

Thanks to all who spent time evaluating and testing.

On to the numbers…

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

High level numbers by release phase:

Beta: 2 (+2);
https://issues.apache.org/jira/browse/CASSANDRA-16552 Anticompaction
appears to race with Compaction - raised as a blocking issue revealed
during RC evaluation
https://issues.apache.org/jira/browse/CASSANDRA-16524 SSL failures after
upgrade - ascertained this week as an impacting issue. Potential fix is
proposed.
RC: 16 (-4); 11 in-flight;

Top-level metrics:
Total tickets in 4.0: 1602 (-7)
Remaining tickets represent 1.a% of total scope

Created vs. resolved trended solidly positive on this interval.

Where you can help:

* Any attention on the newly ascertained blocking flaws would be appreciated
https://issues.apache.org/jira/browse/CASSANDRA-16552
https://issues.apache.org/jira/browse/CASSANDRA-16524

*Needs Reviewer:
1 RC tickets up for review with no reviewer
https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=355&quickFilter=1661&quickFilter=1659

*No assignee:
1 RC ticket in “Ready to Commit”. Possibly mischaracterized, but won’t
clarify at this hour.
https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=355&quickFilter=1661&quickFilter=1658

*Tickets stalled for a week:
6 GA tickets stalled.
https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=355&quickFilter=1661&quickFilter=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 hard work on the project.

-- 
Adam Holmberg
e. adam.holmb...@datastax.com
w. www.datastax.com

Re: Are we ready for 4.0.0 (GA) ?

[Adam Holmberg]

To the point of "long-term observability over flakies":

I will mention here that we intend to deploy a tool called Butler that we
have developed and used internally for a while. It compliments Jenkins to
present different views of test results, allowing developers to better
ascertain those tests that are flaky vs failing vs new regressions. We
already have a server provisioned for public hosting. The application
requires a bit of work to generalize for this project. We've been putting
it on while focused on getting 4.0 over the line, but should be getting to
it soon after.

On Mon, Jun 14, 2021 at 11:33 AM Mick Semb Wever  wrote:

> Are we ready to cut 4.0.0 (GA) once the following tickets land?
>
>  CASSANDRA-16733 – Allow operators to disable 'ALTER ... DROP COMPACT
> STORAGE' statements"
>  CASSANDRA-16669 – Password obfuscation for DCL audit log statements
>  CASSANDRA-16735 – Adding columns via ALTER TABLE can generate corrupt
> sstables
>
>
> A bit more background.
>
> 1. On our 4.0 GA board there's a few other tickets, which have priority but
> are not blockers for a GA release.
>
> https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=355&quickFilter=1661
>
>  CASSANDRA-16715 – WEBSITE - June 2021 updates
>  CASSANDRA-12519 – dtest failure in
> offline_tools_test.TestOfflineTools.sstableofflinerelevel_test
>  CASSANDRA-16681 – org.apache.cassandra.utils.memory.LongBufferPoolTest -
> tests are flaky
>  CASSANDRA-16689 – Flaky LeaveAndBootstrapTest
>
>
> 2. We also said we would get 5 green CI runs in a row. Progress on that
> front
> has been slow and risks delaying GA and our user base. It has had priority
> and there's been lots of momentum which is persisting: lots of flaky fixes
> committed; and the following are being discussed to keep pushing it in the
> right direction…
>  - Long-term observability over flakies
>  - Jenkins agent observability (infra stability)
>
> The past weeks has seen good progress on stability of ci-cassandra.a.o with
> the introduction of cpu docker limits imposed, and better monitoring of the
> agents so we can ensure we get the saturation and load we want. Dockerising
> the cqlshlib tests is also in progress.
>
> The alternative to a 4.0.0 GA release is a 4.0-rc2 release.
> Should the next release be: 4.0.0 (GA) or 4.0-rc2 ?
>


-- 
Adam Holmberg
e. adam.holmb...@datastax.com
w. www.datastax.com

Re: Welcome Adam Holmberg as Cassandra committer

[Adam Holmberg]

Thanks, all. It's been a humbling experience and a privilege to work with
this community in varying capacities.
I'm looking forward to more.

On Tue, Aug 17, 2021 at 1:54 PM Scott Andreas  wrote:

> Congratulations, Adam! 🎉
>
> 
> From: Joseph Lynch 
> Sent: Tuesday, August 17, 2021 7:44 AM
> To: dev@cassandra.apache.org
> Subject: Re: Welcome Adam Holmberg as Cassandra committer
>
> Congratulations Adam!
>
> On Tue, Aug 17, 2021 at 10:25 AM Jordan West  wrote:
> >
> > Congrats Adam!
> >
> > On Tue, Aug 17, 2021 at 5:51 AM Paulo Motta 
> > wrote:
> >
> > > Congratulations and well deserved Adam!
> > >
> > > Em ter., 17 de ago. de 2021 às 03:58, Sumanth Pasupuleti <
> > > sumanth.pasupuleti...@gmail.com> escreveu:
> > >
> > > > Congratulations Adam!!
> > > >
> > > > On Mon, Aug 16, 2021 at 10:32 PM Berenguer Blasi <
> > > berenguerbl...@gmail.com
> > > > >
> > > > wrote:
> > > >
> > > > > Well done Adam, congrats!
> > > > >
> > > > > On 16/8/21 18:27, Andrés de la Peña wrote:
> > > > > > Congrats Adam, well deserved!
> > > > > >
> > > > > > On Mon, 16 Aug 2021 at 17:14, Patrick McFadin <
> pmcfa...@gmail.com>
> > > > > wrote:
> > > > > >
> > > > > >> Great to see you on the committer list Adam!
> > > > > >>
> > > > > >> On Mon, Aug 16, 2021 at 7:06 AM Jonathan Ellis <
> jbel...@gmail.com>
> > > > > wrote:
> > > > > >>
> > > > > >>> Well deserved.  Congratulations!
> > > > > >>>
> > > > > >>> On Mon, Aug 16, 2021 at 5:57 AM Benjamin Lerer <
> ble...@apache.org>
> > > > > >> wrote:
> > > > > >>>>  The PMC members are pleased to announce that Adam Holmberg
> has
> > > > > >> accepted
> > > > > >>>> the invitation to become committer.
> > > > > >>>>
> > > > > >>>> Thanks a lot, Adam, for everything you have done for the
> project
> > > all
> > > > > >>> these
> > > > > >>>> years.
> > > > > >>>>
> > > > > >>>> Congratulations and welcome
> > > > > >>>>
> > > > > >>>> The Apache Cassandra PMC members
> > > > > >>>>
> > > > > >>>
> > > > > >>> --
> > > > > >>> 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
> > > > >
> > > > >
> > > >
> > >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>

PerRowSecondaryIndex Multiple Load

[Adam Holmberg]

I've been studying and experimenting some with the SecondaryIndex API,
specifically extending the PerRowSecondaryIndex class.

I understand from this recent
thread<http://mail-archives.apache.org/mod_mbox/cassandra-dev/201205.mbox/%3CCAMYB=b6c9HTDgOFHQS-UwS4UF2a6NiMs3+C++iG3M8z4xgzn=g...@mail.gmail.com%3E>that
this feature is not yet widely used, but I was hoping someone could
shed some light on its intended concept of operation:

My intuition was to specify my custom index for every column in the column
family that I want to trigger an update for this index. This has the
desired effect for a 'built' index as new row mutations arrive. What I'm
confused about is what happens as the index is built for the first time.
What I'm seeing is that an asynchronous build is kicked off for every
column to which this index is attached (which is obviously undesirable).

It's plain to see why this is happening following the SecondaryIndexManager
reload/addIndexedColumn routines. Now what I'm wondering is if there is
room for improvement here:

Should the Manager wait to initiate an index build until the last column
has been added to a given rowLevelIndex? Or is the impetus on the
PerRowSecondaryIndex implementation to 'fool' the manager into bypassing
the build until the last column is added?

My gut says the former would be preferred since the latter could be a
fragile use of the Interface, but I'm just getting into this area and maybe
I'm thinking about things wrong.

Any input would be appreciated.

Regards,
Adam Holmberg