You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cassandra.apache.org by Benedict Elliott Smith <be...@apache.org> on 2020/12/08 11:33:43 UTC
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" <sa...@beobal.com> 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-unsubscribe@cassandra.apache.org
For additional commands, e-mail: dev-help@cassandra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
For additional commands, e-mail: dev-help@cassandra.apache.org
Re: [DISCUSS] Bringing protocol v5 out of beta and dropping support
from 3.11.x
Posted by Oleksandr Petrov <ol...@gmail.com>.
> Nit-picking, "beta" isn't sounding like the most accurate classifier
here. It sounds to me more like it is "in development", i.e. 'dev', rather
than beta.
I agree that `dev` rather than `beta` is a better classifier. We probably
should rename it at least internally and in the spec. That might be harder
to do in drivers since usually they're offering backward-compatible APIs;
maybe there we could deprecate `allowBetaVersions` and introduce
`allowDevelopmentVersions`.
On Tue, Dec 15, 2020 at 6:29 PM Sam Tunnicliffe <sa...@beobal.com> wrote:
> > What's the verdict now for CASSANDRA-14973 ?
>
> My aim is to have a C* patch and PRs for the python and java drivers this
> week, but really there's nothing to block cutting a new C* beta now (or
> whenever we're ready).
>
> > On 15 Dec 2020, at 15:39, Mick Semb Wever <mc...@apache.org> wrote:
> >
> >>
> >> To use a beta flag, one absolutely has to have matching server
> >> and client versions, since otherwise things can break in unexpected
> ways.
> >> In fact, this specific issue makes it easy since you'd see that
> something
> >> has changed immediately.
> >>
> >
> >
> > That could certainly deserve better documentation. For example, an extra
> > sentence at
> >
> https://github.com/apache/cassandra/blob/trunk/doc/native_protocol_v5.spec#L140-L142
> >
> > And it would also be awesome to see this on the website docs. It's a bit
> of
> > tribal knowledge and crawling jira tickets atm.
> >
> > I think it can also be made more explicit here by what we mean by
> "matching
> > server and client versions". To my understanding this is not explicit
> > versions within V5, as there is only that, but just
> > different build/implementation versions. And that this basically also
> means
> > mixed server versions are outside the scope of the beta flag.
> >
> > Nit-picking, "beta" isn't sounding like the most accurate classifier
> here.
> > It sounds to me more like it is "in development", i.e. 'dev', rather than
> > beta.
> >
> >
> >> +1 to have 4.0 with v5.
> >
> >
> > I agree, v6 is not needed. What's the verdict now for CASSANDRA-14973 ?
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> For additional commands, e-mail: dev-help@cassandra.apache.org
>
>
--
alex p
Re: [DISCUSS] Bringing protocol v5 out of beta and dropping support
from 3.11.x
Posted by Sam Tunnicliffe <sa...@beobal.com>.
> What's the verdict now for CASSANDRA-14973 ?
My aim is to have a C* patch and PRs for the python and java drivers this week, but really there's nothing to block cutting a new C* beta now (or whenever we're ready).
> On 15 Dec 2020, at 15:39, Mick Semb Wever <mc...@apache.org> wrote:
>
>>
>> To use a beta flag, one absolutely has to have matching server
>> and client versions, since otherwise things can break in unexpected ways.
>> In fact, this specific issue makes it easy since you'd see that something
>> has changed immediately.
>>
>
>
> That could certainly deserve better documentation. For example, an extra
> sentence at
> https://github.com/apache/cassandra/blob/trunk/doc/native_protocol_v5.spec#L140-L142
>
> And it would also be awesome to see this on the website docs. It's a bit of
> tribal knowledge and crawling jira tickets atm.
>
> I think it can also be made more explicit here by what we mean by "matching
> server and client versions". To my understanding this is not explicit
> versions within V5, as there is only that, but just
> different build/implementation versions. And that this basically also means
> mixed server versions are outside the scope of the beta flag.
>
> Nit-picking, "beta" isn't sounding like the most accurate classifier here.
> It sounds to me more like it is "in development", i.e. 'dev', rather than
> beta.
>
>
>> +1 to have 4.0 with v5.
>
>
> I agree, v6 is not needed. What's the verdict now for CASSANDRA-14973 ?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
For additional commands, e-mail: dev-help@cassandra.apache.org
Re: [DISCUSS] Bringing protocol v5 out of beta and dropping support
from 3.11.x
Posted by Mick Semb Wever <mc...@apache.org>.
>
> To use a beta flag, one absolutely has to have matching server
> and client versions, since otherwise things can break in unexpected ways.
> In fact, this specific issue makes it easy since you'd see that something
> has changed immediately.
>
That could certainly deserve better documentation. For example, an extra
sentence at
https://github.com/apache/cassandra/blob/trunk/doc/native_protocol_v5.spec#L140-L142
And it would also be awesome to see this on the website docs. It's a bit of
tribal knowledge and crawling jira tickets atm.
I think it can also be made more explicit here by what we mean by "matching
server and client versions". To my understanding this is not explicit
versions within V5, as there is only that, but just
different build/implementation versions. And that this basically also means
mixed server versions are outside the scope of the beta flag.
Nit-picking, "beta" isn't sounding like the most accurate classifier here.
It sounds to me more like it is "in development", i.e. 'dev', rather than
beta.
> +1 to have 4.0 with v5.
I agree, v6 is not needed. What's the verdict now for CASSANDRA-14973 ?
Re: [DISCUSS] Bringing protocol v5 out of beta and dropping support
from 3.11.x
Posted by Oleksandr Petrov <ol...@gmail.com>.
I wanted to point out that beta version of the protocol was created [1]
only for development purposes:
> This is primarily useful for driver authors to start work against a new
protocol version when the work on that spans multiple releases. Users would
not generally be expected to utilize this flag, although it could
potentially be used to offer early feedback on new protocol features.
Even at the time of creating [1], it was expected that development of the
new protocol version would span multiple versions. Unless release of the
new protocol version strictly coincides with a major version bump, even a
major one. To use a beta flag, one absolutely has to have matching server
and client versions, since otherwise things can break in unexpected ways.
In fact, this specific issue makes it easy since you'd see that something
has changed immediately.
+1 to have 4.0 with v5.
[1] https://issues.apache.org/jira/browse/CASSANDRA-12142
On Fri, Dec 11, 2020 at 5:02 PM Sam Tunnicliffe <sa...@beobal.com> wrote:
>
> After a little bit of investigation, it turns out that we can't bring v5
> out of beta in 3.11 as there are already a number of v5 features which 3.11
> doesn't support. This necessarily couples the C*, protocol and driver
> versions. For instance, java driver 3.0.x is able to support v5 with 3.11,
> but not with 4.0 (and the inverse is true of driver 3.10.x). Going back to
> the genesis of v5 in CASSANDRA-10786, this was always the intent:
>
> "v5 beta" will mean different things at different times, and there
> might be errors when an older driver version (supporting "v5 beta with new
> feature A") connects to a newer C* version (supporting "v5 beta with
> new features A and B"). But with the provision that "bad things can happen
> when you're in beta" that's acceptable, so we don't need to make things any
> more complicated." [1]
>
> This simplifies things, we promote v5 out of beta in trunk only with no
> need to bump the framing format to v6-beta. If clients currently using
> v5-beta on 3.11.x want to upgrade their drivers, they must either revert to
> v4 or upgrade the cluster to 4.0. Because CI uses the same python driver
> version for all C* branches, we'll need to make dtests which require v5
> exclusive to 4.0, which I'll take care of. Tickets already exist for the
> python and java drivers ([2],[3],[4]), but we'll need to bundle a SNAPSHOT
> java driver with C* temporarily for testing. I'll file a 4.0-rc blocker to
> replace it with a release version, as we've done previously.
>
> [1]
> https://issues.apache.org/jira/browse/CASSANDRA-10786?focusedCommentId=15344506&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15344506
> [2] https://datastax-oss.atlassian.net/browse/PYTHON-1232
> [3] https://datastax-oss.atlassian.net/browse/JAVA-2704
> [4] https://datastax-oss.atlassian.net/browse/JAVA-2705
>
>
> > On 9 Dec 2020, at 11:02, Sam Tunnicliffe <sa...@beobal.com> wrote:
> >
> >
> >
> >> On 9 Dec 2020, at 02:41, Sumanth Pasupuleti <
> sumanth.pasupuleti.is@gmail.com> wrote:
> >>
> >> +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 <mc...@apache.org> 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+?
> >>>
> >
> >
> > Technically, it *could* come out of beta in 4.0, but stay as it is in
> 3.11. That is, the v5 protocol itself would be identical in both C*
> versions, but there would be some considerations on the client side.
> Namely, if connecting to a cluster with any 3.11 nodes, clients would need
> to set the beta flag in CQL frame (meaning a frame in v5 terms). Any 4.0
> nodes in the cluster would simply ignore the flag, as it wouldn't be
> required for v5 connections. So the most straightforward path would be
> probably to promote v5 out of beta in the next 3.11 and 4.0-beta releases.
> Clients would just need to ensure that they stay on a *current* driver
> (i.e. one which sets that flag for v5) until after upgrading clusters to
> either the latest 3.11 or 4.0-beta releases.
> >
> > I have patches for C*, java and python drivers ready, so I'll file a
> JIRA and open some PRs.
> >
> >
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> > For additional commands, e-mail: dev-help@cassandra.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> For additional commands, e-mail: dev-help@cassandra.apache.org
>
>
--
alex p
Re: [DISCUSS] Bringing protocol v5 out of beta and dropping support
from 3.11.x
Posted by Sam Tunnicliffe <sa...@beobal.com>.
After a little bit of investigation, it turns out that we can't bring v5 out of beta in 3.11 as there are already a number of v5 features which 3.11 doesn't support. This necessarily couples the C*, protocol and driver versions. For instance, java driver 3.0.x is able to support v5 with 3.11, but not with 4.0 (and the inverse is true of driver 3.10.x). Going back to the genesis of v5 in CASSANDRA-10786, this was always the intent:
"v5 beta" will mean different things at different times, and there might be errors when an older driver version (supporting "v5 beta with new feature A") connects to a newer C* version (supporting "v5 beta with new features A and B"). But with the provision that "bad things can happen when you're in beta" that's acceptable, so we don't need to make things any more complicated." [1]
This simplifies things, we promote v5 out of beta in trunk only with no need to bump the framing format to v6-beta. If clients currently using v5-beta on 3.11.x want to upgrade their drivers, they must either revert to v4 or upgrade the cluster to 4.0. Because CI uses the same python driver version for all C* branches, we'll need to make dtests which require v5 exclusive to 4.0, which I'll take care of. Tickets already exist for the python and java drivers ([2],[3],[4]), but we'll need to bundle a SNAPSHOT java driver with C* temporarily for testing. I'll file a 4.0-rc blocker to replace it with a release version, as we've done previously.
[1] https://issues.apache.org/jira/browse/CASSANDRA-10786?focusedCommentId=15344506&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15344506
[2] https://datastax-oss.atlassian.net/browse/PYTHON-1232
[3] https://datastax-oss.atlassian.net/browse/JAVA-2704
[4] https://datastax-oss.atlassian.net/browse/JAVA-2705
> On 9 Dec 2020, at 11:02, Sam Tunnicliffe <sa...@beobal.com> wrote:
>
>
>
>> On 9 Dec 2020, at 02:41, Sumanth Pasupuleti <su...@gmail.com> wrote:
>>
>> +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 <mc...@apache.org> 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+?
>>>
>
>
> Technically, it *could* come out of beta in 4.0, but stay as it is in 3.11. That is, the v5 protocol itself would be identical in both C* versions, but there would be some considerations on the client side. Namely, if connecting to a cluster with any 3.11 nodes, clients would need to set the beta flag in CQL frame (meaning a frame in v5 terms). Any 4.0 nodes in the cluster would simply ignore the flag, as it wouldn't be required for v5 connections. So the most straightforward path would be probably to promote v5 out of beta in the next 3.11 and 4.0-beta releases. Clients would just need to ensure that they stay on a *current* driver (i.e. one which sets that flag for v5) until after upgrading clusters to either the latest 3.11 or 4.0-beta releases.
>
> I have patches for C*, java and python drivers ready, so I'll file a JIRA and open some PRs.
>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> For additional commands, e-mail: dev-help@cassandra.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
For additional commands, e-mail: dev-help@cassandra.apache.org
Re: [DISCUSS] Bringing protocol v5 out of beta and dropping support
from 3.11.x
Posted by Sam Tunnicliffe <sa...@beobal.com>.
> On 9 Dec 2020, at 02:41, Sumanth Pasupuleti <su...@gmail.com> wrote:
>
> +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 <mc...@apache.org> 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+?
>>
Technically, it *could* come out of beta in 4.0, but stay as it is in 3.11. That is, the v5 protocol itself would be identical in both C* versions, but there would be some considerations on the client side. Namely, if connecting to a cluster with any 3.11 nodes, clients would need to set the beta flag in CQL frame (meaning a frame in v5 terms). Any 4.0 nodes in the cluster would simply ignore the flag, as it wouldn't be required for v5 connections. So the most straightforward path would be probably to promote v5 out of beta in the next 3.11 and 4.0-beta releases. Clients would just need to ensure that they stay on a *current* driver (i.e. one which sets that flag for v5) until after upgrading clusters to either the latest 3.11 or 4.0-beta releases.
I have patches for C*, java and python drivers ready, so I'll file a JIRA and open some PRs.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
For additional commands, e-mail: dev-help@cassandra.apache.org
Re: [DISCUSS] Bringing protocol v5 out of beta and dropping support
from 3.11.x
Posted by Sumanth Pasupuleti <su...@gmail.com>.
+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 <mc...@apache.org> 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
Posted by Mick Semb Wever <mc...@apache.org>.
> …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
Posted by Sam Tunnicliffe <sa...@beobal.com>.
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 <be...@apache.org> 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" <sa...@beobal.com> 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-unsubscribe@cassandra.apache.org
> For additional commands, e-mail: dev-help@cassandra.apache.org
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> For additional commands, e-mail: dev-help@cassandra.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
For additional commands, e-mail: dev-help@cassandra.apache.org