Re: [DISCUSS] Bringing protocol v5 out of beta and dropping support from 3.11.x
+1 to moving v5-beta changes in trunk to new protocol v6. Regarding 3.11 and v5, I suppose we could say, v5 could never get matured beyond beta, but not sure if it would be confusing to see v6 while v5 is still in beta (curious on others' thoughts as well) On Tue, Dec 8, 2020 at 12:33 PM Mick Semb Wever wrote: > > …move to v6 for the new protocol to avoid this issue > > > +1, feels more the "grown-up thing to do". > > > > > Perhaps we should skip v5… > > We could finalise v5 as it was prior to the new framing format, then > create v6-beta in trunk only with the 15299 changes. > > > Would v5 come out of beta then in 3.11?, or would it stay as beta forever, > with the focus on maturing v6 in 4.0+? >
Re: [DISCUSS] Bringing protocol v5 out of beta and dropping support from 3.11.x
> …move to v6 for the new protocol to avoid this issue +1, feels more the "grown-up thing to do". > > Perhaps we should skip v5… > We could finalise v5 as it was prior to the new framing format, then create v6-beta in trunk only with the 15299 changes. Would v5 come out of beta then in 3.11?, or would it stay as beta forever, with the focus on maturing v6 in 4.0+?
Re: Cassandra 4.0 Status 2020-12-07
Hey folks. I appreciate the pulse these emails lend to this release, but at times they can be a bit sobering. While things continue to be pointed in the right direction, you can see it’s been a bit of a slog and it got me wondering “when might 4.0 be done?”. I did a little Jira digging to use recent history as evidence of bandwidth, and create a projection including the following assumptions: - Holidays degrade December and January production (Jan to a lesser degree) - Aside from that, stakeholders continue to direct the same energy and resource - We will see more ticket expansion as QA Testing headlines are decomposed into sub-tasks - The rate of bug/flaky test tickets optimistically diminishes as we are stabilizing and adding tests around existing functionality Obviously, as with any projection there is a bit of hand-waving. I’m happy to discuss my methodology more, but without getting into the weeds I just thought I’d toss it out for discussion: This model has 4.0 bottoming out on tickets at approximately the end of March. Now I’m curious: how does this align with others’ expectations? Is this timeline acceptable? Does anyone have, or know of any plans that would change this significantly? I’m interested to hear how this strikes you. On Mon, Dec 7, 2020 at 1:08 PM Jon Meredith wrote: > 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 > > -- Adam Holmberg e. adam.holmb...@datastax.com w.
Re: [DISCUSS] Bringing protocol v5 out of beta and dropping support from 3.11.x
Ye, that would be the alternative. We could finalise v5 as it was prior to the new framing format, then create v6-beta in trunk only with the 15299 changes. > On 8 Dec 2020, at 11:33, Benedict Elliott Smith wrote: > > Perhaps we should skip v5, and move to v6 for the new protocol to avoid this > issue? > > On 08/12/2020, 10:53, "Sam Tunnicliffe" wrote: > >CASSANDRA-15299 has revised the wire format of CQL native protocol to add > a framing layer around the existing CQL messages. This is targetted at > protocol v5, which is (still) currently in beta. There's a small problem with > this though; while v5-beta is supported in Cassandra 3.11.x and 4.0.0, the > new wire format is only committed to trunk. This means that if clients > upgrade to a version of their driver which supports the new wire format > (3.10.0 for the java driver, python driver is not yet offically released), > connections to Cassandra 3.11.x nodes will break if the client specifies > v5-beta as the preferred protocol version. > >Of course, any protocol changes that landed in v5-beta have had the > potential to cause this breakage and in some ways this particular change has > a better failure mode as it prevents incompatible clients from connecting at > all. As we have no intention of backporting the new wire format to 3.11.x, > and because v5-beta has always been characterised as an unsupported, dev-only > preview, I'm proposing we remove support for it from the 3.11 line. At the > same time, we should promote v5 from beta and create a new v6-beta for future > development (CASSANDRA-14973). > >If there are no objections, I'll file a JIRA for 3.11.x and post a patch > shortly. > >Thanks, >Sam > > >- >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: [DISCUSS] Bringing protocol v5 out of beta and dropping support from 3.11.x
Perhaps we should skip v5, and move to v6 for the new protocol to avoid this issue? On 08/12/2020, 10:53, "Sam Tunnicliffe" wrote: CASSANDRA-15299 has revised the wire format of CQL native protocol to add a framing layer around the existing CQL messages. This is targetted at protocol v5, which is (still) currently in beta. There's a small problem with this though; while v5-beta is supported in Cassandra 3.11.x and 4.0.0, the new wire format is only committed to trunk. This means that if clients upgrade to a version of their driver which supports the new wire format (3.10.0 for the java driver, python driver is not yet offically released), connections to Cassandra 3.11.x nodes will break if the client specifies v5-beta as the preferred protocol version. Of course, any protocol changes that landed in v5-beta have had the potential to cause this breakage and in some ways this particular change has a better failure mode as it prevents incompatible clients from connecting at all. As we have no intention of backporting the new wire format to 3.11.x, and because v5-beta has always been characterised as an unsupported, dev-only preview, I'm proposing we remove support for it from the 3.11 line. At the same time, we should promote v5 from beta and create a new v6-beta for future development (CASSANDRA-14973). If there are no objections, I'll file a JIRA for 3.11.x and post a patch shortly. Thanks, Sam - 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
[DISCUSS] Bringing protocol v5 out of beta and dropping support from 3.11.x
CASSANDRA-15299 has revised the wire format of CQL native protocol to add a framing layer around the existing CQL messages. This is targetted at protocol v5, which is (still) currently in beta. There's a small problem with this though; while v5-beta is supported in Cassandra 3.11.x and 4.0.0, the new wire format is only committed to trunk. This means that if clients upgrade to a version of their driver which supports the new wire format (3.10.0 for the java driver, python driver is not yet offically released), connections to Cassandra 3.11.x nodes will break if the client specifies v5-beta as the preferred protocol version. Of course, any protocol changes that landed in v5-beta have had the potential to cause this breakage and in some ways this particular change has a better failure mode as it prevents incompatible clients from connecting at all. As we have no intention of backporting the new wire format to 3.11.x, and because v5-beta has always been characterised as an unsupported, dev-only preview, I'm proposing we remove support for it from the 3.11 line. At the same time, we should promote v5 from beta and create a new v6-beta for future development (CASSANDRA-14973). If there are no objections, I'll file a JIRA for 3.11.x and post a patch shortly. Thanks, Sam - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
Re: cassandra--dtest: module 'pytest' has no attribute 'config'
Hi Adam,
Thanks for your reply.
It's indeed a pytest version issue. Resolved by using virtualenv as
mentioned in the doc :)
cheers
Le lun. 7 déc. 2020 à 21:44, Adam Holmberg a
écrit :
> 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
>
--
Cordialement;
Ahmed ELJAMI
