Cassandra 3.11 cqlsh doesn't work with latest JDK
Hi everyone,
I have Apache Cassandra 3.11.6 with SSL encryption, CentOS Linux release
7.9, python 2.7.5. JDK and python are coming from operating system.
I have updated today operating system and with that I've got new JDK
$ java -version
openjdk version "1.8.0_292"
OpenJDK Runtime Environment (build 1.8.0_292-b10)
OpenJDK 64-Bit Server VM (build 25.292-b10, mixed mode)
Now when I try to connect to my local instance of Cassandra with cqlsh I'm
getting error:
$ cqlsh --ssl -u cassandra -p cassandra
Connection error: ('Unable to connect to any servers', {'127.0.0.1':
error(1, u"Tried connecting to [('127.0.0.1', 9142)]. Last error: [SSL:
WRONG_VERSION_NUMBER] wrong version number (_ssl.c:618)")})
Apparently, latest release of JDK *_292 disabled TLS1.0 and TLS1.1.
Is this known issue ? Is there is something I could do to quickly remedy
the situation ?
Thanks in advance,
Maxim.
[DISCUSS] Semantic versioning after 4.0
*** Proposal *** Aligned to the agreed-upon annual cadence of supported releases, let's use semantic versioning for better ecosystem operatibility, and to promote API awareness and compatibility support from documentation to tests. *** Background *** The recent¹ dev ML thread 'Releases after 4.0' landed on an annual release cadence, and for promoting an always shippable trunk (repeated again in the roadmap thread²). A digression that occurred in the thread was around the use of semantic versioning, and the possible role of properly using major and minor versions within the annual release cycle. This proposal is an attempt to take those points of view and build them on everything else we have agreed upon so far. *** Ecosystem Operability *** The Cassandra codebase has an ecosystem around it. From downstream projects to vendors providing support for versions to managed DBaaS. We can help them out with semver, and by providing unreleased minor versions through the year. Unreleased means we don’t do a formal Apache release approval, we just bump the version in `build.xml`. Downstream projects face overhead when, either trying to keep up with trunk through each annual development cycle, or trying to rebase against a whole year's worth of development once each year. Unreleased versions will provide safe points for the ecosystem to plug into and keep up with. Vendors are also free to support and provide hot-fixes and back ports on these unreleased versions, outside of the community's efforts or concerns. And of course semver provides a lot of value to downstream codebases. *** API and Compatibility Awareness *** The idea here is to provide awareness and improved documentation to our APIs, their audience, and to what compatibility is required on them. Personally, I still struggle getting my head around all the ways Cassandra can break its APIs and what to think about and to test when coding. This is important for ensuring availability during upgrades (mix-version clusters), and again important if we want to introduce data-safe downgrades. This stuff doesn't get (battle-) tested enough. The native protocol bump to v6 was an example for the need to be better at documenting and testing what's involved (across the ecosystem). The consequences of breaking compatibility range from documentation, and tests, to mixed versioned clusters, upgrade and rollback operations. Semantic versioning is a way of foreseeing and preparing for such changes. In practice this can be done a) using different fixVersions in jira ticket, and b) lazy-incrementing the major version in trunk when the first breaking change lands in the development cycle. For example, we enter the next development cycle with Jira fixVersions of "4.X" and "5.X", and an initial trunk version of "4.1". Then when a committer merges the first "5.X" ticket they bump trunk's version up to "5.0". This approach incentivises patches to be aware and to better document the breakage, and comes with the added benefit for the ecosystem of identifying where in the development cycle the compatibility first broke. Some examples of compatibility areas are CQL, Native Protocol, gossip, JMX, Metrics, Virtual Tables, SSTable, CDC, Commitlog, FQL, and Auditing. Many of these don't have enough documentation of how they are versioned and compatibility. As we add pluggability (i.e. SPIs) both the need to document this, and to be closer with the ecosystem increases. *** Example for 2021-2022 *** Illustrating this in action, with a cadence of a minor version every quarter, - today, we branch `cassandra-4.0` and increment trunk to 4.1 - commits roll into trunk, no "5.X" tickets have landed yet, - in July we increment the version to 4.2, no release is made or announced, - commits continue to roll into trunk, still no "5.X" tickets have landed yet, - in October we increment the version to 4.3 - commits continue to roll into trunk, a "5.X" patch lands, trunk is incremented to 5.0 - in January 2022 we increment the value to 5.1, no release is made or announced, - commits continue to roll into trunk, - in April 2022 we formally release 5.1 and branch `cassandra-5.1` The cadence of those minor versions could be anything, quarterly, monthly or on-demand. This practice will force us to organise and automate dealing with version changes, creating our release branches, organising our test upgrade version paths. I'm gathering that process currently in CASSANDRA-16642. Jeremiah originally (and in more depth) illustrated this here: https://lists.apache.org/thread.html/r9b53342e6992cf98e8b95e763f63d19c798765be3bd86436f07afa8c%40%3Cdev.cassandra.apache.org%3E *** Concerns *** Addressing the questions and concerns that were previously raised. We have a problematic history with release versioning. This proposal is not tick-tock. It is about known best-practices around semver version numbers. This does not add the overhead of additional releases or release branches to the community.
Re: [DISCUSS] Semantic versioning after 4.0
+1 for doing this (or something similar). It will give more clarity to downstream users about the compatibility of a given release. -Jeremiah > On Apr 30, 2021, at 12:45 PM, Mick Semb Wever wrote: > > *** Proposal *** > Aligned to the agreed-upon annual cadence of supported releases, let's > use semantic versioning for better ecosystem operatibility, and to > promote API awareness and compatibility support from documentation to > tests. > > > *** Background *** > The recent¹ dev ML thread 'Releases after 4.0' landed on an annual > release cadence, and for promoting an always shippable trunk (repeated > again in the roadmap thread²). > > A digression that occurred in the thread was around the use of > semantic versioning, and the possible role of properly using major and > minor versions within the annual release cycle. This proposal is an > attempt to take those points of view and build them on everything else > we have agreed upon so far. > > > *** Ecosystem Operability *** > The Cassandra codebase has an ecosystem around it. From downstream > projects to vendors providing support for versions to managed DBaaS. > > We can help them out with semver, and by providing unreleased minor > versions through the year. Unreleased means we don’t do a formal > Apache release approval, we just bump the version in `build.xml`. > Downstream projects face overhead when, either trying to keep up with > trunk through each annual development cycle, or trying to rebase > against a whole year's worth of development once each year. > Unreleased versions will provide safe points for the ecosystem to plug > into and keep up with. Vendors are also free to support and provide > hot-fixes and back ports on these unreleased versions, outside of the > community's efforts or concerns. And of course semver provides a lot > of value to downstream codebases. > > > *** API and Compatibility Awareness *** > The idea here is to provide awareness and improved documentation to > our APIs, their audience, and to what compatibility is required on > them. Personally, I still struggle getting my head around all the ways > Cassandra can break its APIs and what to think about and to test when > coding. > > This is important for ensuring availability during upgrades > (mix-version clusters), and again important if we want to introduce > data-safe downgrades. This stuff doesn't get (battle-) tested enough. > The native protocol bump to v6 was an example for the need to be > better at documenting and testing what's involved (across the > ecosystem). > > The consequences of breaking compatibility range from documentation, > and tests, to mixed versioned clusters, upgrade and rollback > operations. Semantic versioning is a way of foreseeing and preparing > for such changes. In practice this can be done > a) using different fixVersions in jira ticket, and > b) lazy-incrementing the major version in trunk when the first > breaking change lands in the development cycle. > > For example, we enter the next development cycle with Jira fixVersions > of "4.X" and "5.X", and an initial trunk version of "4.1". Then when a > committer merges the first "5.X" ticket they bump trunk's version up > to "5.0". > > This approach incentivises patches to be aware and to better document > the breakage, and comes with the added benefit for the ecosystem of > identifying where in the development cycle the compatibility first > broke. > > Some examples of compatibility areas are CQL, Native Protocol, gossip, > JMX, Metrics, Virtual Tables, SSTable, CDC, Commitlog, FQL, and > Auditing. Many of these don't have enough documentation of how they > are versioned and compatibility. As we add pluggability (i.e. SPIs) > both the need to document this, and to be closer with the ecosystem > increases. > > > *** Example for 2021-2022 *** > Illustrating this in action, with a cadence of a minor version every quarter, > > - today, we branch `cassandra-4.0` and increment trunk to 4.1 > - commits roll into trunk, no "5.X" tickets have landed yet, > - in July we increment the version to 4.2, no release is made or announced, > - commits continue to roll into trunk, still no "5.X" tickets have landed yet, > - in October we increment the version to 4.3 > - commits continue to roll into trunk, a "5.X" patch lands, trunk is > incremented to 5.0 > - in January 2022 we increment the value to 5.1, no release is made or > announced, > - commits continue to roll into trunk, > - in April 2022 we formally release 5.1 and branch `cassandra-5.1` > > > The cadence of those minor versions could be anything, quarterly, > monthly or on-demand. This practice will force us to organise and > automate dealing with version changes, creating our release branches, > organising our test upgrade version paths. I'm gathering that process > currently in CASSANDRA-16642. > > Jeremiah originally (and in more depth) illustrated this here: > https://lists.apache.org/thread.html/r9b53342e6992cf98e8
Re: [DISCUSS] Semantic versioning after 4.0
Success of this seems predicated on keeping trunk shippable, which means getting Harry and things like adelphi into CI/CD sooner rather than later. I've definitely come around to Ariel's thinking about the value of having an *actually* shippable trunk + the value of feature flags for things. It's a heavy lift to ensure shippability with something as complex as Cassandra, but if we can figure that out it'll go a long way towards us being able to move forward faster as a project while remaining safe. +1 On Fri, Apr 30, 2021 at 2:52 PM Jeremiah D Jordan wrote: > +1 for doing this (or something similar). It will give more clarity to > downstream users about the compatibility of a given release. > > -Jeremiah > > > On Apr 30, 2021, at 12:45 PM, Mick Semb Wever wrote: > > > > *** Proposal *** > > Aligned to the agreed-upon annual cadence of supported releases, let's > > use semantic versioning for better ecosystem operatibility, and to > > promote API awareness and compatibility support from documentation to > > tests. > > > > > > *** Background *** > > The recent¹ dev ML thread 'Releases after 4.0' landed on an annual > > release cadence, and for promoting an always shippable trunk (repeated > > again in the roadmap thread²). > > > > A digression that occurred in the thread was around the use of > > semantic versioning, and the possible role of properly using major and > > minor versions within the annual release cycle. This proposal is an > > attempt to take those points of view and build them on everything else > > we have agreed upon so far. > > > > > > *** Ecosystem Operability *** > > The Cassandra codebase has an ecosystem around it. From downstream > > projects to vendors providing support for versions to managed DBaaS. > > > > We can help them out with semver, and by providing unreleased minor > > versions through the year. Unreleased means we don’t do a formal > > Apache release approval, we just bump the version in `build.xml`. > > Downstream projects face overhead when, either trying to keep up with > > trunk through each annual development cycle, or trying to rebase > > against a whole year's worth of development once each year. > > Unreleased versions will provide safe points for the ecosystem to plug > > into and keep up with. Vendors are also free to support and provide > > hot-fixes and back ports on these unreleased versions, outside of the > > community's efforts or concerns. And of course semver provides a lot > > of value to downstream codebases. > > > > > > *** API and Compatibility Awareness *** > > The idea here is to provide awareness and improved documentation to > > our APIs, their audience, and to what compatibility is required on > > them. Personally, I still struggle getting my head around all the ways > > Cassandra can break its APIs and what to think about and to test when > > coding. > > > > This is important for ensuring availability during upgrades > > (mix-version clusters), and again important if we want to introduce > > data-safe downgrades. This stuff doesn't get (battle-) tested enough. > > The native protocol bump to v6 was an example for the need to be > > better at documenting and testing what's involved (across the > > ecosystem). > > > > The consequences of breaking compatibility range from documentation, > > and tests, to mixed versioned clusters, upgrade and rollback > > operations. Semantic versioning is a way of foreseeing and preparing > > for such changes. In practice this can be done > > a) using different fixVersions in jira ticket, and > > b) lazy-incrementing the major version in trunk when the first > > breaking change lands in the development cycle. > > > > For example, we enter the next development cycle with Jira fixVersions > > of "4.X" and "5.X", and an initial trunk version of "4.1". Then when a > > committer merges the first "5.X" ticket they bump trunk's version up > > to "5.0". > > > > This approach incentivises patches to be aware and to better document > > the breakage, and comes with the added benefit for the ecosystem of > > identifying where in the development cycle the compatibility first > > broke. > > > > Some examples of compatibility areas are CQL, Native Protocol, gossip, > > JMX, Metrics, Virtual Tables, SSTable, CDC, Commitlog, FQL, and > > Auditing. Many of these don't have enough documentation of how they > > are versioned and compatibility. As we add pluggability (i.e. SPIs) > > both the need to document this, and to be closer with the ecosystem > > increases. > > > > > > *** Example for 2021-2022 *** > > Illustrating this in action, with a cadence of a minor version every > quarter, > > > > - today, we branch `cassandra-4.0` and increment trunk to 4.1 > > - commits roll into trunk, no "5.X" tickets have landed yet, > > - in July we increment the version to 4.2, no release is made or > announced, > > - commits continue to roll into trunk, still no "5.X" tickets have > landed yet, > > - in October we increment the version to
Re: [DISCUSS] Semantic versioning after 4.0
+1 to semver, shippable trunk, feature flags, and better documentation about feature support and compatibility edges - we should have a single page with a table of version x feature, with a summary and links to detailed explanations of everything important a user should be aware of. I didn't really understand the unreleased versions proposal though. On 30/04/2021, 20:00, "Joshua McKenzie" wrote: Success of this seems predicated on keeping trunk shippable, which means getting Harry and things like adelphi into CI/CD sooner rather than later. I've definitely come around to Ariel's thinking about the value of having an *actually* shippable trunk + the value of feature flags for things. It's a heavy lift to ensure shippability with something as complex as Cassandra, but if we can figure that out it'll go a long way towards us being able to move forward faster as a project while remaining safe. +1 On Fri, Apr 30, 2021 at 2:52 PM Jeremiah D Jordan wrote: > +1 for doing this (or something similar). It will give more clarity to > downstream users about the compatibility of a given release. > > -Jeremiah > > > On Apr 30, 2021, at 12:45 PM, Mick Semb Wever wrote: > > > > *** Proposal *** > > Aligned to the agreed-upon annual cadence of supported releases, let's > > use semantic versioning for better ecosystem operatibility, and to > > promote API awareness and compatibility support from documentation to > > tests. > > > > > > *** Background *** > > The recent¹ dev ML thread 'Releases after 4.0' landed on an annual > > release cadence, and for promoting an always shippable trunk (repeated > > again in the roadmap thread²). > > > > A digression that occurred in the thread was around the use of > > semantic versioning, and the possible role of properly using major and > > minor versions within the annual release cycle. This proposal is an > > attempt to take those points of view and build them on everything else > > we have agreed upon so far. > > > > > > *** Ecosystem Operability *** > > The Cassandra codebase has an ecosystem around it. From downstream > > projects to vendors providing support for versions to managed DBaaS. > > > > We can help them out with semver, and by providing unreleased minor > > versions through the year. Unreleased means we don’t do a formal > > Apache release approval, we just bump the version in `build.xml`. > > Downstream projects face overhead when, either trying to keep up with > > trunk through each annual development cycle, or trying to rebase > > against a whole year's worth of development once each year. > > Unreleased versions will provide safe points for the ecosystem to plug > > into and keep up with. Vendors are also free to support and provide > > hot-fixes and back ports on these unreleased versions, outside of the > > community's efforts or concerns. And of course semver provides a lot > > of value to downstream codebases. > > > > > > *** API and Compatibility Awareness *** > > The idea here is to provide awareness and improved documentation to > > our APIs, their audience, and to what compatibility is required on > > them. Personally, I still struggle getting my head around all the ways > > Cassandra can break its APIs and what to think about and to test when > > coding. > > > > This is important for ensuring availability during upgrades > > (mix-version clusters), and again important if we want to introduce > > data-safe downgrades. This stuff doesn't get (battle-) tested enough. > > The native protocol bump to v6 was an example for the need to be > > better at documenting and testing what's involved (across the > > ecosystem). > > > > The consequences of breaking compatibility range from documentation, > > and tests, to mixed versioned clusters, upgrade and rollback > > operations. Semantic versioning is a way of foreseeing and preparing > > for such changes. In practice this can be done > > a) using different fixVersions in jira ticket, and > > b) lazy-incrementing the major version in trunk when the first > > breaking change lands in the development cycle. > > > > For example, we enter the next development cycle with Jira fixVersions > > of "4.X" and "5.X", and an initial trunk version of "4.1". Then when a > > committer merges the first "5.X" ticket they bump trunk's version up > > to "5.0". > > > > This approach incentivises patches to be aware and to better document > > the breakage, and comes with the added benefit for the ecosystem of > > identifying where in the development cycle the compatibility first > > broke. > > > > Some examples of compatibility areas are CQL, Native Protocol, gossip, > > JMX, Metric
