You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cassandra.apache.org by Joshua McKenzie <jm...@apache.org> on 2020/10/08 18:48:35 UTC
Supported upgrade path for 4.0
Related JIRA ticket: https://issues.apache.org/jira/browse/CASSANDRA-15588
Description:
"We've historically had numerous bugs concerning upgrading clusters from
one version to the other. Let's establish the supported upgrade path and
ensure that users can safely perform the upgrades in production."
So the topic of discussion here: what is our supported upgrade path to 4.0?
Is this actually documented on our site or in our documentation? Spent a
few minutes poking around and didn't find anything.
Anyone have an opinion here or any formal prior art for us to build on?
Re: Supported upgrade path for 4.0
Posted by Sumanth Pasupuleti <su...@gmail.com>.
+1 to officially supporting 3.0 to 4.0, in addition to 3.11 to 4.0 upgrade
paths
On Thu, Oct 8, 2020 at 10:33 PM Jeff Jirsa <jj...@gmail.com> wrote:
>
> I assumed it would be 3.0.x and 3.11.x
>
> I don’t know why we’d make 3.0-4.0 unofficial/unsupported - there’s no
> technical reason I’ve seen
>
> > On Oct 8, 2020, at 9:21 PM, Anthony Grasso <an...@gmail.com>
> wrote:
> >
> > Hi Josh,
> >
> > This is a really good question. I agree with David about making sure this
> > is clearly documented.
> >
> > As far as the supported upgrade path goes, I think we should officially
> > support only 3.11.x. I do understand the idea of giving users the
> > flexibility to upgrade from 3.0.x. However, the simpler we can make the
> > upgrade path the better. As you mentioned, historically there have been
> > numerous upgrade bugs. To that, having one upgrade path will make
> > maintenance and support easier.
> >
> > Kind regards,
> >
> >> On Fri, 9 Oct 2020 at 07:36, David Capwell <dc...@gmail.com> wrote:
> >>
> >> Thanks for bringing this up, we really should document this and make
> sure
> >> the different upgrade paths are clearly documented and have proper
> >> coverage.
> >>
> >> There was a conversation in slack a while back (started from
> >> https://the-asf.slack.com/archives/CK23JSY2K/p1595906733435000) but not
> >> formal or voted on, but the current upgrade targets were 3.0.x and
> 3.11.x
> >> (do others feel we should support other versions as well and if so
> what?).
> >>
> >> For features, COMPACT STORAGE is getting a lot of attention right now,
> so
> >> would love to see clarity on how we go from a cluster with COMPACT
> STORAGE
> >> to 4.0 (is there min version support, what is the upgrade path, what
> about
> >> deleted rows, etc.).
> >>
> >> This is what I know about the current state of 4.0 upgrades at least.
> >>
> >> On Thu, Oct 8, 2020 at 11:48 AM Joshua McKenzie <jm...@apache.org>
> >> wrote:
> >>
> >>> Related JIRA ticket:
> >> https://issues.apache.org/jira/browse/CASSANDRA-15588
> >>>
> >>> Description:
> >>>
> >>> "We've historically had numerous bugs concerning upgrading clusters
> from
> >>> one version to the other. Let's establish the supported upgrade path
> and
> >>> ensure that users can safely perform the upgrades in production."
> >>>
> >>> So the topic of discussion here: what is our supported upgrade path to
> >> 4.0?
> >>> Is this actually documented on our site or in our documentation? Spent
> a
> >>> few minutes poking around and didn't find anything.
> >>>
> >>> Anyone have an opinion here or any formal prior art for us to build on?
> >>>
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> For additional commands, e-mail: dev-help@cassandra.apache.org
>
>
Re: Supported upgrade path for 4.0
Posted by Jeff Jirsa <jj...@gmail.com>.
I assumed it would be 3.0.x and 3.11.x
I don’t know why we’d make 3.0-4.0 unofficial/unsupported - there’s no technical reason I’ve seen
> On Oct 8, 2020, at 9:21 PM, Anthony Grasso <an...@gmail.com> wrote:
>
> Hi Josh,
>
> This is a really good question. I agree with David about making sure this
> is clearly documented.
>
> As far as the supported upgrade path goes, I think we should officially
> support only 3.11.x. I do understand the idea of giving users the
> flexibility to upgrade from 3.0.x. However, the simpler we can make the
> upgrade path the better. As you mentioned, historically there have been
> numerous upgrade bugs. To that, having one upgrade path will make
> maintenance and support easier.
>
> Kind regards,
>
>> On Fri, 9 Oct 2020 at 07:36, David Capwell <dc...@gmail.com> wrote:
>>
>> Thanks for bringing this up, we really should document this and make sure
>> the different upgrade paths are clearly documented and have proper
>> coverage.
>>
>> There was a conversation in slack a while back (started from
>> https://the-asf.slack.com/archives/CK23JSY2K/p1595906733435000) but not
>> formal or voted on, but the current upgrade targets were 3.0.x and 3.11.x
>> (do others feel we should support other versions as well and if so what?).
>>
>> For features, COMPACT STORAGE is getting a lot of attention right now, so
>> would love to see clarity on how we go from a cluster with COMPACT STORAGE
>> to 4.0 (is there min version support, what is the upgrade path, what about
>> deleted rows, etc.).
>>
>> This is what I know about the current state of 4.0 upgrades at least.
>>
>> On Thu, Oct 8, 2020 at 11:48 AM Joshua McKenzie <jm...@apache.org>
>> wrote:
>>
>>> Related JIRA ticket:
>> https://issues.apache.org/jira/browse/CASSANDRA-15588
>>>
>>> Description:
>>>
>>> "We've historically had numerous bugs concerning upgrading clusters from
>>> one version to the other. Let's establish the supported upgrade path and
>>> ensure that users can safely perform the upgrades in production."
>>>
>>> So the topic of discussion here: what is our supported upgrade path to
>> 4.0?
>>> Is this actually documented on our site or in our documentation? Spent a
>>> few minutes poking around and didn't find anything.
>>>
>>> Anyone have an opinion here or any formal prior art for us to build on?
>>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
For additional commands, e-mail: dev-help@cassandra.apache.org
Re: Supported upgrade path for 4.0
Posted by Anthony Grasso <an...@gmail.com>.
Hi Josh,
This is a really good question. I agree with David about making sure this
is clearly documented.
As far as the supported upgrade path goes, I think we should officially
support only 3.11.x. I do understand the idea of giving users the
flexibility to upgrade from 3.0.x. However, the simpler we can make the
upgrade path the better. As you mentioned, historically there have been
numerous upgrade bugs. To that, having one upgrade path will make
maintenance and support easier.
Kind regards,
On Fri, 9 Oct 2020 at 07:36, David Capwell <dc...@gmail.com> wrote:
> Thanks for bringing this up, we really should document this and make sure
> the different upgrade paths are clearly documented and have proper
> coverage.
>
> There was a conversation in slack a while back (started from
> https://the-asf.slack.com/archives/CK23JSY2K/p1595906733435000) but not
> formal or voted on, but the current upgrade targets were 3.0.x and 3.11.x
> (do others feel we should support other versions as well and if so what?).
>
> For features, COMPACT STORAGE is getting a lot of attention right now, so
> would love to see clarity on how we go from a cluster with COMPACT STORAGE
> to 4.0 (is there min version support, what is the upgrade path, what about
> deleted rows, etc.).
>
> This is what I know about the current state of 4.0 upgrades at least.
>
> On Thu, Oct 8, 2020 at 11:48 AM Joshua McKenzie <jm...@apache.org>
> wrote:
>
> > Related JIRA ticket:
> https://issues.apache.org/jira/browse/CASSANDRA-15588
> >
> > Description:
> >
> > "We've historically had numerous bugs concerning upgrading clusters from
> > one version to the other. Let's establish the supported upgrade path and
> > ensure that users can safely perform the upgrades in production."
> >
> > So the topic of discussion here: what is our supported upgrade path to
> 4.0?
> > Is this actually documented on our site or in our documentation? Spent a
> > few minutes poking around and didn't find anything.
> >
> > Anyone have an opinion here or any formal prior art for us to build on?
> >
>
Re: Supported upgrade path for 4.0
Posted by David Capwell <dc...@gmail.com>.
Thanks for bringing this up, we really should document this and make sure
the different upgrade paths are clearly documented and have proper coverage.
There was a conversation in slack a while back (started from
https://the-asf.slack.com/archives/CK23JSY2K/p1595906733435000) but not
formal or voted on, but the current upgrade targets were 3.0.x and 3.11.x
(do others feel we should support other versions as well and if so what?).
For features, COMPACT STORAGE is getting a lot of attention right now, so
would love to see clarity on how we go from a cluster with COMPACT STORAGE
to 4.0 (is there min version support, what is the upgrade path, what about
deleted rows, etc.).
This is what I know about the current state of 4.0 upgrades at least.
On Thu, Oct 8, 2020 at 11:48 AM Joshua McKenzie <jm...@apache.org>
wrote:
> Related JIRA ticket: https://issues.apache.org/jira/browse/CASSANDRA-15588
>
> Description:
>
> "We've historically had numerous bugs concerning upgrading clusters from
> one version to the other. Let's establish the supported upgrade path and
> ensure that users can safely perform the upgrades in production."
>
> So the topic of discussion here: what is our supported upgrade path to 4.0?
> Is this actually documented on our site or in our documentation? Spent a
> few minutes poking around and didn't find anything.
>
> Anyone have an opinion here or any formal prior art for us to build on?
>
Re: Supported upgrade path for 4.0
Posted by Erick Ramirez <er...@datastax.com>.
If a user asked me today, I would tell them to test the following paths
before attempting it in production:
- 2.1.x ---> 2.1.latest ---> 3.11.latest ---> 4.0
- 2.2.x ---> 2.2.latest ---> 3.11.latest ---> 4.0
- 3.0.x ---> 3.0.latest ---> 4.0
- 3.x ---> 3.11.latest ---> 4.0
The upgrade paths from 2.1/2.2/3.0/3.x to 3.11 are well-established and
known today although the procedure isn't documented on the Apache website.
I'd be happy to get drafts in if there are no objections. Cheers!
Re: Supported upgrade path for 4.0
Posted by Joshua McKenzie <jm...@apache.org>.
2.1.x -> 2.1.latest -> [3.0.latest | 3.11.latest] -> 4.0
2.2.x -> 2.2.latest -> [3.0.latest | 3.11.latest] -> 4.0
3.0 -> 3.0.latest -> 4.0
3.x -> 3.11.latest -> 4.0
Got a little lost in your email Jeremy.
Sounds like (from Ben | Instaclustr and Mick | TLP experience) there's
confidence to move forward testing and documenting the following:
Tested:
From → To
2.1 → 3.0 → 4.0
2.1 → 3.11 → 4.0
3.0 → 3.11 → 4.0
3.0 → 4.0
3.11 → 4.0
And Recommended:
From → To
2.1 → 3.11 → 4.0
3.0 → 4.0
3.11 → 4.0
Distinction between what we've tested and what we recommend, and 1 clear
path From any supported version To the latest GA.
If we all agree on the above, we should probably now discuss what "Tested"
means. :)
On Sun, Oct 11, 2020 at 7:57 PM, Jeremy Hanna <je...@gmail.com>
wrote:
> So to reiterate the recommended/tested paths that I get from this thread:
>
> 2.1.x -> 2.1.latest -> [3.0.latest | 3.11.latest] -> 4.0
> 2.2.x -> 2.2.latest -> [3.0.latest | 3.11.latest] -> 4.0
> 3.0 -> 3.0.latest -> 4.0
> 3.x -> 3.11.latest -> 4.0
>
> I just wanted to be explicit about getting to the latest in the current
> line you're in before upgrading to reduce risks and test surface area by
> upgrading from a single '.latest' version. That and in case there are
> additional fixes added in this upgrade test process to make the '.latest'
> version more stable for the upgrade. Also we hadn't mentioned 2.2 which
> some people are running and is currently supported by the project.
>
> Something that makes [3.0.latest | 3.11.latest] as a midpoint less of a
> risk is that both 3.0.latest and 3.11.latest use the same sstable version
> (md). That sstable version came about in 3.0.18/3.11.4. If people are on
> earlier versions of 3.0 or 3.x, we should consider recommending that they
> upgrade to 3.0.latest or 3.11.latest, run upgradessttables, and then go to
> 4.0 to just make sure they go from md to na (4.0). Just to save people from
> looking it up, the last major change to the sstable format was in
> 3.0.18/3.11.4 with version md to correct sstable min/max metadata. See
> https://issues.apache.org/jira/browse/CASSANDRA-14861 and https://github.
> com/apache/cassandra/blob/cassandra-3.11/src/java/org/apache/cassandra/io/
> sstable/format/big/BigFormat.java#L128. I've been surprised to see some
> clusters that back API gateways running 3.7 for example.
>
> On Oct 12, 2020, at 8:32 AM, Scott Andreas <sc...@paradoxica.net> wrote:
>
> Great, thanks Ben!
>
> The primary configuration my colleagues and I will be vetting is the 3.0.x
> -> 4.0 path (implicitly, 2.1 -> 3.0 -> 4.0). From a quality + safety
> perspective we will be ensuring that it’s a smooth ride for folks who opt
> for this route; though no major concerns on my part with the project
> recommending 2.1 -> 3.11 -> 4.0 aside from not having experienced it
> myself.
>
> On Oct 11, 2020, at 12:47 AM, Ben Slater <be...@instaclustr.com>
> wrote:
>
> Just to add to Mick's point, we (Instaclustr) have also been running and
> recommending 3.11.x by default. It's currently by far the most common
> version in our managed fleet and our last 3.0.x cluster will likely be
> upgraded shortly. 3.11.x is also our recommendation for consulting and
> support customers. I'd therefore support Mick's recommendation (really
> based on our experience with and confidence in 3.11.x rather than being
> able to point to specific issues off hand) that 2.*->3.11.x->4.0 is the
> preferred upgrade path. We will do testing on 3.11.x to 4.0 upgrade but I
> can't see us doing any work on 3.0 to 4.0.
>
> Cheers
> Ben
>
> ---
>
> *Ben Slater**Chief Product Officer*
>
> <https://www.instaclustr.com/platform/>
>
> <https://www.facebook.com/instaclustr> <https://twitter.com/instaclustr>
> <https://www.linkedin.com/company/instaclustr>
>
> Read our latest technical blog posts here
> <https://www.instaclustr.com/blog/>.
>
> This email has been sent on behalf of Instaclustr Pty. Limited (Australia)
> and Instaclustr Inc (USA).
>
> This email and any attachments may contain confidential and legally
> privileged information. If you are not the intended recipient, do not copy
> or disclose its content, but please reply to this email immediately and
> highlight the error to the sender and then immediately delete the message.
>
> On Sun, 11 Oct 2020 at 06:42, Mick Semb Wever <mc...@apache.org> wrote:
>
> "3.11 performs close to parity with 2.1/2.2. 3.0 does not. If we
>
> recommend
>
> people upgrade from 2.1 -> 3.0 -> 4.0, we are asking them to have a
>
> cluster
>
> in a regressed performance state for potentially months as they execute
> their upgrade."
>
> Did I get anything wrong here Mick? ^
>
> That's correct Josh.
>
> From tickets like those listed, and from experience, we recommend folk
> avoid 3.0 altogether. This has only been made more evident by witnessing
> the benefits from 3.0 → 3.11 upgrades.
>
> My recommendation remains 2.*→3.11→4.0. And I don't believe I'm alone.
> Though if a user was already on 3.0, then I would (of course) recommend an
> upgrade directly to 4.0.
>
> I feel like I'm just splitting straws at this point, since we have
> accepted
> (folk willing to help with) both paths to 4.0, and I can't see how we stop
> recommending 2.*→3.11 upgrades.
>
> --------------------------------------------------------------------- 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: Supported upgrade path for 4.0
Posted by Jeremy Hanna <je...@gmail.com>.
So to reiterate the recommended/tested paths that I get from this thread:
2.1.x -> 2.1.latest -> [3.0.latest | 3.11.latest] -> 4.0
2.2.x -> 2.2.latest -> [3.0.latest | 3.11.latest] -> 4.0
3.0 -> 3.0.latest -> 4.0
3.x -> 3.11.latest -> 4.0
I just wanted to be explicit about getting to the latest in the current line you're in before upgrading to reduce risks and test surface area by upgrading from a single '.latest' version. That and in case there are additional fixes added in this upgrade test process to make the '.latest' version more stable for the upgrade. Also we hadn't mentioned 2.2 which some people are running and is currently supported by the project.
Something that makes [3.0.latest | 3.11.latest] as a midpoint less of a risk is that both 3.0.latest and 3.11.latest use the same sstable version (md). That sstable version came about in 3.0.18/3.11.4. If people are on earlier versions of 3.0 or 3.x, we should consider recommending that they upgrade to 3.0.latest or 3.11.latest, run upgradessttables, and then go to 4.0 to just make sure they go from md to na (4.0). Just to save people from looking it up, the last major change to the sstable format was in 3.0.18/3.11.4 with version md to correct sstable min/max metadata. See https://issues.apache.org/jira/browse/CASSANDRA-14861 and https://github.com/apache/cassandra/blob/cassandra-3.11/src/java/org/apache/cassandra/io/sstable/format/big/BigFormat.java#L128. I've been surprised to see some clusters that back API gateways running 3.7 for example.
> On Oct 12, 2020, at 8:32 AM, Scott Andreas <sc...@paradoxica.net> wrote:
>
> Great, thanks Ben!
>
> The primary configuration my colleagues and I will be vetting is the 3.0.x -> 4.0 path (implicitly, 2.1 -> 3.0 -> 4.0). From a quality + safety perspective we will be ensuring that it’s a smooth ride for folks who opt for this route; though no major concerns on my part with the project recommending 2.1 -> 3.11 -> 4.0 aside from not having experienced it myself.
>
>> On Oct 11, 2020, at 12:47 AM, Ben Slater <be...@instaclustr.com> wrote:
>>
>> Just to add to Mick's point, we (Instaclustr) have also been running and
>> recommending 3.11.x by default. It's currently by far the most common
>> version in our managed fleet and our last 3.0.x cluster will likely be
>> upgraded shortly. 3.11.x is also our recommendation for consulting and
>> support customers. I'd therefore support Mick's recommendation (really
>> based on our experience with and confidence in 3.11.x rather than being
>> able to point to specific issues off hand) that 2.*->3.11.x->4.0 is the
>> preferred upgrade path. We will do testing on 3.11.x to 4.0 upgrade but I
>> can't see us doing any work on 3.0 to 4.0.
>>
>> Cheers
>> Ben
>>
>> ---
>>
>>
>> *Ben Slater**Chief Product Officer*
>>
>> <https://www.instaclustr.com/platform/>
>>
>> <https://www.facebook.com/instaclustr> <https://twitter.com/instaclustr>
>> <https://www.linkedin.com/company/instaclustr>
>>
>> Read our latest technical blog posts here
>> <https://www.instaclustr.com/blog/>.
>>
>> This email has been sent on behalf of Instaclustr Pty. Limited (Australia)
>> and Instaclustr Inc (USA).
>>
>> This email and any attachments may contain confidential and legally
>> privileged information. If you are not the intended recipient, do not copy
>> or disclose its content, but please reply to this email immediately and
>> highlight the error to the sender and then immediately delete the message.
>>
>>
>> On Sun, 11 Oct 2020 at 06:42, Mick Semb Wever <mc...@apache.org> wrote:
>>
>>>> "3.11 performs close to parity with 2.1/2.2. 3.0 does not. If we
>>> recommend
>>>> people upgrade from 2.1 -> 3.0 -> 4.0, we are asking them to have a
>>> cluster
>>>> in a regressed performance state for potentially months as they execute
>>>> their upgrade."
>>>>
>>>> Did I get anything wrong here Mick? ^
>>>>
>>>
>>>
>>> That's correct Josh.
>>>
>>> From tickets like those listed, and from experience, we recommend folk
>>> avoid 3.0 altogether. This has only been made more evident by witnessing
>>> the benefits from 3.0 → 3.11 upgrades.
>>>
>>> My recommendation remains 2.*→3.11→4.0. And I don't believe I'm alone.
>>> Though if a user was already on 3.0, then I would (of course) recommend an
>>> upgrade directly to 4.0.
>>>
>>> I feel like I'm just splitting straws at this point, since we have accepted
>>> (folk willing to help with) both paths to 4.0, and I can't see how we stop
>>> recommending 2.*→3.11 upgrades.
>>>
>
>
> ---------------------------------------------------------------------
> 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: Supported upgrade path for 4.0
Posted by Scott Andreas <sc...@paradoxica.net>.
Great, thanks Ben!
The primary configuration my colleagues and I will be vetting is the 3.0.x -> 4.0 path (implicitly, 2.1 -> 3.0 -> 4.0). From a quality + safety perspective we will be ensuring that it’s a smooth ride for folks who opt for this route; though no major concerns on my part with the project recommending 2.1 -> 3.11 -> 4.0 aside from not having experienced it myself.
> On Oct 11, 2020, at 12:47 AM, Ben Slater <be...@instaclustr.com> wrote:
>
> Just to add to Mick's point, we (Instaclustr) have also been running and
> recommending 3.11.x by default. It's currently by far the most common
> version in our managed fleet and our last 3.0.x cluster will likely be
> upgraded shortly. 3.11.x is also our recommendation for consulting and
> support customers. I'd therefore support Mick's recommendation (really
> based on our experience with and confidence in 3.11.x rather than being
> able to point to specific issues off hand) that 2.*->3.11.x->4.0 is the
> preferred upgrade path. We will do testing on 3.11.x to 4.0 upgrade but I
> can't see us doing any work on 3.0 to 4.0.
>
> Cheers
> Ben
>
> ---
>
>
> *Ben Slater**Chief Product Officer*
>
> <https://www.instaclustr.com/platform/>
>
> <https://www.facebook.com/instaclustr> <https://twitter.com/instaclustr>
> <https://www.linkedin.com/company/instaclustr>
>
> Read our latest technical blog posts here
> <https://www.instaclustr.com/blog/>.
>
> This email has been sent on behalf of Instaclustr Pty. Limited (Australia)
> and Instaclustr Inc (USA).
>
> This email and any attachments may contain confidential and legally
> privileged information. If you are not the intended recipient, do not copy
> or disclose its content, but please reply to this email immediately and
> highlight the error to the sender and then immediately delete the message.
>
>
> On Sun, 11 Oct 2020 at 06:42, Mick Semb Wever <mc...@apache.org> wrote:
>
>>> "3.11 performs close to parity with 2.1/2.2. 3.0 does not. If we
>> recommend
>>> people upgrade from 2.1 -> 3.0 -> 4.0, we are asking them to have a
>> cluster
>>> in a regressed performance state for potentially months as they execute
>>> their upgrade."
>>>
>>> Did I get anything wrong here Mick? ^
>>>
>>
>>
>> That's correct Josh.
>>
>> From tickets like those listed, and from experience, we recommend folk
>> avoid 3.0 altogether. This has only been made more evident by witnessing
>> the benefits from 3.0 → 3.11 upgrades.
>>
>> My recommendation remains 2.*→3.11→4.0. And I don't believe I'm alone.
>> Though if a user was already on 3.0, then I would (of course) recommend an
>> upgrade directly to 4.0.
>>
>> I feel like I'm just splitting straws at this point, since we have accepted
>> (folk willing to help with) both paths to 4.0, and I can't see how we stop
>> recommending 2.*→3.11 upgrades.
>>
Re: Supported upgrade path for 4.0
Posted by Ben Slater <be...@instaclustr.com>.
Just to add to Mick's point, we (Instaclustr) have also been running and
recommending 3.11.x by default. It's currently by far the most common
version in our managed fleet and our last 3.0.x cluster will likely be
upgraded shortly. 3.11.x is also our recommendation for consulting and
support customers. I'd therefore support Mick's recommendation (really
based on our experience with and confidence in 3.11.x rather than being
able to point to specific issues off hand) that 2.*->3.11.x->4.0 is the
preferred upgrade path. We will do testing on 3.11.x to 4.0 upgrade but I
can't see us doing any work on 3.0 to 4.0.
Cheers
Ben
---
*Ben Slater**Chief Product Officer*
<https://www.instaclustr.com/platform/>
<https://www.facebook.com/instaclustr> <https://twitter.com/instaclustr>
<https://www.linkedin.com/company/instaclustr>
Read our latest technical blog posts here
<https://www.instaclustr.com/blog/>.
This email has been sent on behalf of Instaclustr Pty. Limited (Australia)
and Instaclustr Inc (USA).
This email and any attachments may contain confidential and legally
privileged information. If you are not the intended recipient, do not copy
or disclose its content, but please reply to this email immediately and
highlight the error to the sender and then immediately delete the message.
On Sun, 11 Oct 2020 at 06:42, Mick Semb Wever <mc...@apache.org> wrote:
> > "3.11 performs close to parity with 2.1/2.2. 3.0 does not. If we
> recommend
> > people upgrade from 2.1 -> 3.0 -> 4.0, we are asking them to have a
> cluster
> > in a regressed performance state for potentially months as they execute
> > their upgrade."
> >
> > Did I get anything wrong here Mick? ^
> >
>
>
> That's correct Josh.
>
> From tickets like those listed, and from experience, we recommend folk
> avoid 3.0 altogether. This has only been made more evident by witnessing
> the benefits from 3.0 → 3.11 upgrades.
>
> My recommendation remains 2.*→3.11→4.0. And I don't believe I'm alone.
> Though if a user was already on 3.0, then I would (of course) recommend an
> upgrade directly to 4.0.
>
> I feel like I'm just splitting straws at this point, since we have accepted
> (folk willing to help with) both paths to 4.0, and I can't see how we stop
> recommending 2.*→3.11 upgrades.
>
Re: Supported upgrade path for 4.0
Posted by Mick Semb Wever <mc...@apache.org>.
> "3.11 performs close to parity with 2.1/2.2. 3.0 does not. If we recommend
> people upgrade from 2.1 -> 3.0 -> 4.0, we are asking them to have a cluster
> in a regressed performance state for potentially months as they execute
> their upgrade."
>
> Did I get anything wrong here Mick? ^
>
That's correct Josh.
From tickets like those listed, and from experience, we recommend folk
avoid 3.0 altogether. This has only been made more evident by witnessing
the benefits from 3.0 → 3.11 upgrades.
My recommendation remains 2.*→3.11→4.0. And I don't believe I'm alone.
Though if a user was already on 3.0, then I would (of course) recommend an
upgrade directly to 4.0.
I feel like I'm just splitting straws at this point, since we have accepted
(folk willing to help with) both paths to 4.0, and I can't see how we stop
recommending 2.*→3.11 upgrades.
Re: Supported upgrade path for 4.0
Posted by Joshua McKenzie <jm...@apache.org>.
Hm. We have a wrinkle that's thankfully testable.
I've been talking back and forth w/Mick about his and the TLP team's
experience upgrading clusters to 3.0 vs. upgrading to 3.11. The
observations and assertion: 3.0 has performance regressions from 2.1 that
were fixed through the tick-tock line as well as several significant
optimizations in 3.11 not present on 3.0. Some examples:
- https://issues.apache.org/jira/browse/CASSANDRA-12269
- https://issues.apache.org/jira/browse/CASSANDRA-11206
- https://issues.apache.org/jira/browse/CASSANDRA-12731
- https://issues.apache.org/jira/browse/CASSANDRA-9766
- https://issues.apache.org/jira/browse/CASSANDRA-11623
Do we as a project have a sense of whether 3.0's performance is, at this
time, on parity with the 2.1/2.2 line of releases? As I framed it to Mick
on slack, a hypothesis we can test:
"3.11 performs close to parity with 2.1/2.2. 3.0 does not. If we recommend
people upgrade from 2.1 -> 3.0 -> 4.0, we are asking them to have a cluster
in a regressed performance state for potentially months as they execute
their upgrade."
Did I get anything wrong here Mick? ^
I'll work with some folks to test this assertion. *pending results*, what
that would amount to is the following change to the latest state on this
thread:
From → To:
2.1 → 3.11 → 4.0
3.0 → 4.0
3.11 → 4.0
Fundamentally it doesn't change that we need to confirm 3.0 → 4.0 as well
as 3.11 → 4.0, it strictly amounts to a change in recommendation for 2.1
cluster destinations.
Until we have more information on this, I believe we shouldn't document a
recommendation yet. I'll treat this with urgency.
On Sat, Oct 10, 2020 at 6:05 AM, Benedict Elliott Smith <benedict@apache.org
> wrote:
> This sounds eminently sensible to me.
>
> On 09/10/2020, 19:42, "Joshua McKenzie" <jm...@apache.org> wrote:
>
> Fair point on uncertainties and delaying decisions until strictly required
> so we have more data.
>
> I want to nuance my earlier proposal and what we document (sorry for the
> multiple messages; my time is fragmented enough these days that I only have
> thin slices to engage w/stuff like this).
>
> I think we should do a "From → To" model for both testing and supporting
> upgrades and have a point of view as a project for each currently supported
> version of C* in the "From" list. Specifically - we test and recommend the
> following paths:
>
> 1. 2.1 → 3.0 → 4.0
> 2. 3.0 → 4.0 (subset of 1)
> 3. 3.11 → 4.0
>
> There's no value whatsoever in hopping through an interim version if a
> leapfrog is expected to be as tested and stable. The only other alternative
> would be to recommend 2.1 → 3.11 → 4.0 (as Mick alluded to) but that just
> exposes to more deltas from the tick-tock .X line for no added value as you
> mentioned.
>
> We could re-apply the "from-to" testing and support model in future
> releases w/whatever is supported at that time. That way users will be able
> to have a single source of truth on what the project recommends and vets
> for going from wherever they are to the latest.
>
> On Fri, Oct 09, 2020 at 12:05 PM, Benedict Elliott Smith < benedict@
> apache.org> wrote:
>
> There is a sizeable cohort of us who I expect to be primarily focused on
> 3.0->4.0, so if you have a cohort focusing primarily on 3.11->4.0 I think
> we'll be in good shape.
>
> For all subsequent major releases, we test and officially support only 1
> major back
>
> I think we should wait to see what happens before committing ourselves to
> something like this - things like release cadence etc will matter a lot.
> That is *definitely* not to say that I disagree with you, just that I think
> more project future-context is needed to make a decision like this. I
> expect we'll have lots more fun (hopefully positive) conversations around
> topics like this in the coming year, as I have no doubt we all want to
> evolve our approach to releases, and there's no knowing what we'll end up
> deciding (we have done some crazy things in the past __ ).
>
> On 09/10/2020, 16:46, "Joshua McKenzie" <jm...@apache.org> wrote:
>
> I think it's a clean and simple heuristic for the project to say "you can
> safely upgrade to adjacent major versions".
>
> The difficulty we face with 3.0 is that it has made many contributors very
> wary of pre 4.0 code and with good reason. Your point about conservative
> users upgrading later in a cycle resonates Benedict, and reflects on the
> confidence we should or should not have in 3.11. I think it's also
> important to realize that many cluster upgrades can take months, so it's
> not a transient exposure to unknowns in a release.
>
> I propose the following compromise:
>
> 1. For 4.0 GA, we consider the following upgrade paths "tested and
> supported": 2.1 → 3.0 → 3.11 → 4.0, and 2.1 → 3.0 → 4.0
> 2. For all subsequent major releases, we test and officially support only
> 1 major back
> 3. Any contributor can optionally meet whatever bar we set for "tested and
> supported" to allow leapfrogging versions, but we won't constrain GA on
> that.
>
> We have to pay down our debt right now, but if we have to continue to do
> this in the future we're not learning from our mistakes.
>
> Speaking for DataStax, we don't have enough resources to work through the
> new testing work on 40_quality_test, the defects that David is surfacing
> like crazy (well done!), and validating 2 major upgrade paths. If you and a
> set of contributors could take on the 3.0 → 4.0 path Benedict, that'd be a
> great help. I also assume we could all collaborate on the tooling / infra /
> approaches we use for this validation so it wouldn't be a complete re-work.
>
> On Fri, Oct 09, 2020 at 11:02 AM, Benedict Elliott Smith < benedict@
> apache.org> wrote:
>
> Since email is very unclear and context gets lost, I'm personally OK with
> officially supporting all of these upgrade paths, but the spectre was
> raised that this might lead to lost labour due to an increased support
> burden. My view is that 3.0->4.0 is probably a safer upgrade path for users
> and as a result a lower support cost to the project, so I would be happy to
> deprecate 3.0->3.11 if this helps alleviate the concerns of others that
> this would be costly to the project. Alternatively, if we want to support
> both but some feel 3.0->4.0 is burdensome, I would be happy to focus on
> 3.0->4.0 while they focus on the paths I would be happy to deprecate.
>
> On 09/10/2020, 15:49, "Benedict Elliott Smith" <be...@apache.org>
> wrote:
>
> Yeah, and perhaps even drop 2.1 (2.2) -> 3.11 when 4.0 appears.
>
> I think there's anyway a big difference between supported and encouraged.
> I think we should encourage 2.1->3.0->4.0, while maintaining support for
> 2.2->3.0 and 3.0->3.11 for critical bugs only, and 3.11->4.0 in the normal
> way given the userbase that is already on 3.11.
>
> we can expect it to be *stable enough to upgrade through*
>
> I don't know that this is true at all. Most bugs are not found by the
> general userbase, and the most conservative (hence most likely to spot
> problems on upgrade) are generally very late to the party. 2.1(2.2)->3.0 is
> still discovering bugs today, many years after this metric was passed for
> 3.0 - largely as the more sophisticated users upgrade.
>
> On 09/10/2020, 15:40, "Marcus Eriksson" <ma...@apache.org> wrote:
>
> My suggestion for "supported" upgrade paths would be;
>
> 2.1 (2.2) -> 3.0 -> 4.0
> 2.1 (2.2) -> 3.11 -> 4.0
>
> and drop support for 3.0 -> 3.11 when we release 4.0
>
> /Marcus
>
> On 9 October 2020 at 16:12:12, Joshua McKenzie (jmckenzie@apache.org)
> wrote:
>
> Some data that I believe is relevant here.
>
> Numerically it's safe to assume there's over 10,000 ASF C* clusters out in
> the world (5,500 in China alone). In surveys (both informal polling and
> primary research), at least 1/3rd of folks are running the 3.X latest if I
> recall correctly.
>
> Basic conclusions we can draw from these data points:
> 1) There are thousands of clusters running some form of post 3.0, so we
> can expect it to be *stable enough to upgrade through*
> 2) We have to support at least 3.11 → 4.0
>
> If 1/3rd of our users are running 2.1, 1/3rd 3.0, and 1/3rd 3.11
> (hand-waving, probably more in the 25 vs. 40 etc but splitting hairs),
> there's clearly a significant value-add in usability of skipping majors
> (3.0->4.0). Depending on how we define "done" and "supported" for upgrade
> testing, this will represent a significant development burden.
>
> From a *functional MVP* perspective on what upgrade paths we need to
> support, the absolute minimum would be 2.1 → 3.0 → 3.11 → 4.0
>
> If anyone wants to step in and officially support the 3.0 → 4.0 line,
> that's fantastic both for the project community and for users. But as far
> as basic table stakes, I can't think of a logical reason 3.0 → 4.0 as an
> upgraded path should be considered a blocker for releasing 4.0 GA.
>
> On Fri, Oct 09, 2020 at 9:53 AM, Mick Semb Wever wrote:
>
> At The Last Pickle we have always recommended avoiding 3.0, including
> upgrading from 2.2 directly to 3.11.
> We (now DataStax) will continue to recommend that folk upgrade to the
> latest 3.11 before upgrading to 4.0.
>
> To clarify that^, if it wasn't obvious, I wasn't making a statement about
> DataStax at at large, but about those of us at TLP and now the team
> providing the consulting for Apache Cassandra from DataStax.
>
> --------------------------------------------------------------------- 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
>
> --------------------------------------------------------------------- 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: Supported upgrade path for 4.0
Posted by Benedict Elliott Smith <be...@apache.org>.
This sounds eminently sensible to me.
On 09/10/2020, 19:42, "Joshua McKenzie" <jm...@apache.org> wrote:
Fair point on uncertainties and delaying decisions until strictly required
so we have more data.
I want to nuance my earlier proposal and what we document (sorry for the
multiple messages; my time is fragmented enough these days that I only have
thin slices to engage w/stuff like this).
I think we should do a "From → To" model for both testing and supporting
upgrades and have a point of view as a project for each currently supported
version of C* in the "From" list. Specifically - we test and recommend the
following paths:
1. 2.1 → 3.0 → 4.0
2. 3.0 → 4.0 (subset of 1)
3. 3.11 → 4.0
There's no value whatsoever in hopping through an interim version if a
leapfrog is expected to be as tested and stable. The only other alternative
would be to recommend 2.1 → 3.11 → 4.0 (as Mick alluded to) but that just
exposes to more deltas from the tick-tock .X line for no added value as you
mentioned.
We could re-apply the "from-to" testing and support model in future
releases w/whatever is supported at that time. That way users will be able
to have a single source of truth on what the project recommends and vets
for going from wherever they are to the latest.
On Fri, Oct 09, 2020 at 12:05 PM, Benedict Elliott Smith <
benedict@apache.org> wrote:
> There is a sizeable cohort of us who I expect to be primarily focused on
> 3.0->4.0, so if you have a cohort focusing primarily on 3.11->4.0 I think
> we'll be in good shape.
>
> For all subsequent major releases, we test and officially support only 1
> major back
>
> I think we should wait to see what happens before committing ourselves to
> something like this - things like release cadence etc will matter a lot.
> That is *definitely* not to say that I disagree with you, just that I think
> more project future-context is needed to make a decision like this. I
> expect we'll have lots more fun (hopefully positive) conversations around
> topics like this in the coming year, as I have no doubt we all want to
> evolve our approach to releases, and there's no knowing what we'll end up
> deciding (we have done some crazy things in the past __ ).
>
> On 09/10/2020, 16:46, "Joshua McKenzie" <jm...@apache.org> wrote:
>
> I think it's a clean and simple heuristic for the project to say "you can
> safely upgrade to adjacent major versions".
>
> The difficulty we face with 3.0 is that it has made many contributors very
> wary of pre 4.0 code and with good reason. Your point about conservative
> users upgrading later in a cycle resonates Benedict, and reflects on the
> confidence we should or should not have in 3.11. I think it's also
> important to realize that many cluster upgrades can take months, so it's
> not a transient exposure to unknowns in a release.
>
> I propose the following compromise:
>
> 1. For 4.0 GA, we consider the following upgrade paths "tested and
> supported": 2.1 → 3.0 → 3.11 → 4.0, and 2.1 → 3.0 → 4.0
> 2. For all subsequent major releases, we test and officially support only
> 1 major back
> 3. Any contributor can optionally meet whatever bar we set for "tested and
> supported" to allow leapfrogging versions, but we won't constrain GA on
> that.
>
> We have to pay down our debt right now, but if we have to continue to do
> this in the future we're not learning from our mistakes.
>
> Speaking for DataStax, we don't have enough resources to work through the
> new testing work on 40_quality_test, the defects that David is surfacing
> like crazy (well done!), and validating 2 major upgrade paths. If you and a
> set of contributors could take on the 3.0 → 4.0 path Benedict, that'd be a
> great help. I also assume we could all collaborate on the tooling / infra /
> approaches we use for this validation so it wouldn't be a complete re-work.
>
> On Fri, Oct 09, 2020 at 11:02 AM, Benedict Elliott Smith < benedict@
> apache.org> wrote:
>
> Since email is very unclear and context gets lost, I'm personally OK with
> officially supporting all of these upgrade paths, but the spectre was
> raised that this might lead to lost labour due to an increased support
> burden. My view is that 3.0->4.0 is probably a safer upgrade path for users
> and as a result a lower support cost to the project, so I would be happy to
> deprecate 3.0->3.11 if this helps alleviate the concerns of others that
> this would be costly to the project. Alternatively, if we want to support
> both but some feel 3.0->4.0 is burdensome, I would be happy to focus on
> 3.0->4.0 while they focus on the paths I would be happy to deprecate.
>
> On 09/10/2020, 15:49, "Benedict Elliott Smith" <be...@apache.org>
> wrote:
>
> Yeah, and perhaps even drop 2.1 (2.2) -> 3.11 when 4.0 appears.
>
> I think there's anyway a big difference between supported and encouraged.
> I think we should encourage 2.1->3.0->4.0, while maintaining support for
> 2.2->3.0 and 3.0->3.11 for critical bugs only, and 3.11->4.0 in the normal
> way given the userbase that is already on 3.11.
>
> we can expect it to be *stable enough to upgrade through*
>
> I don't know that this is true at all. Most bugs are not found by the
> general userbase, and the most conservative (hence most likely to spot
> problems on upgrade) are generally very late to the party. 2.1(2.2)->3.0 is
> still discovering bugs today, many years after this metric was passed for
> 3.0 - largely as the more sophisticated users upgrade.
>
> On 09/10/2020, 15:40, "Marcus Eriksson" <ma...@apache.org> wrote:
>
> My suggestion for "supported" upgrade paths would be;
>
> 2.1 (2.2) -> 3.0 -> 4.0
> 2.1 (2.2) -> 3.11 -> 4.0
>
> and drop support for 3.0 -> 3.11 when we release 4.0
>
> /Marcus
>
> On 9 October 2020 at 16:12:12, Joshua McKenzie (jmckenzie@apache.org)
> wrote:
>
> Some data that I believe is relevant here.
>
> Numerically it's safe to assume there's over 10,000 ASF C* clusters out in
> the world (5,500 in China alone). In surveys (both informal polling and
> primary research), at least 1/3rd of folks are running the 3.X latest if I
> recall correctly.
>
> Basic conclusions we can draw from these data points:
> 1) There are thousands of clusters running some form of post 3.0, so we
> can expect it to be *stable enough to upgrade through*
> 2) We have to support at least 3.11 → 4.0
>
> If 1/3rd of our users are running 2.1, 1/3rd 3.0, and 1/3rd 3.11
> (hand-waving, probably more in the 25 vs. 40 etc but splitting hairs),
> there's clearly a significant value-add in usability of skipping majors
> (3.0->4.0). Depending on how we define "done" and "supported" for upgrade
> testing, this will represent a significant development burden.
>
> From a *functional MVP* perspective on what upgrade paths we need to
> support, the absolute minimum would be 2.1 → 3.0 → 3.11 → 4.0
>
> If anyone wants to step in and officially support the 3.0 → 4.0 line,
> that's fantastic both for the project community and for users. But as far
> as basic table stakes, I can't think of a logical reason 3.0 → 4.0 as an
> upgraded path should be considered a blocker for releasing 4.0 GA.
>
> On Fri, Oct 09, 2020 at 9:53 AM, Mick Semb Wever wrote:
>
> At The Last Pickle we have always recommended avoiding 3.0, including
> upgrading from 2.2 directly to 3.11.
> We (now DataStax) will continue to recommend that folk upgrade to the
> latest 3.11 before upgrading to 4.0.
>
> To clarify that^, if it wasn't obvious, I wasn't making a statement about
> DataStax at at large, but about those of us at TLP and now the team
> providing the consulting for Apache Cassandra from DataStax.
>
> --------------------------------------------------------------------- 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
>
> --------------------------------------------------------------------- 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: Supported upgrade path for 4.0
Posted by Joshua McKenzie <jm...@apache.org>.
Fair point on uncertainties and delaying decisions until strictly required
so we have more data.
I want to nuance my earlier proposal and what we document (sorry for the
multiple messages; my time is fragmented enough these days that I only have
thin slices to engage w/stuff like this).
I think we should do a "From → To" model for both testing and supporting
upgrades and have a point of view as a project for each currently supported
version of C* in the "From" list. Specifically - we test and recommend the
following paths:
1. 2.1 → 3.0 → 4.0
2. 3.0 → 4.0 (subset of 1)
3. 3.11 → 4.0
There's no value whatsoever in hopping through an interim version if a
leapfrog is expected to be as tested and stable. The only other alternative
would be to recommend 2.1 → 3.11 → 4.0 (as Mick alluded to) but that just
exposes to more deltas from the tick-tock .X line for no added value as you
mentioned.
We could re-apply the "from-to" testing and support model in future
releases w/whatever is supported at that time. That way users will be able
to have a single source of truth on what the project recommends and vets
for going from wherever they are to the latest.
On Fri, Oct 09, 2020 at 12:05 PM, Benedict Elliott Smith <
benedict@apache.org> wrote:
> There is a sizeable cohort of us who I expect to be primarily focused on
> 3.0->4.0, so if you have a cohort focusing primarily on 3.11->4.0 I think
> we'll be in good shape.
>
> For all subsequent major releases, we test and officially support only 1
> major back
>
> I think we should wait to see what happens before committing ourselves to
> something like this - things like release cadence etc will matter a lot.
> That is *definitely* not to say that I disagree with you, just that I think
> more project future-context is needed to make a decision like this. I
> expect we'll have lots more fun (hopefully positive) conversations around
> topics like this in the coming year, as I have no doubt we all want to
> evolve our approach to releases, and there's no knowing what we'll end up
> deciding (we have done some crazy things in the past __ ).
>
> On 09/10/2020, 16:46, "Joshua McKenzie" <jm...@apache.org> wrote:
>
> I think it's a clean and simple heuristic for the project to say "you can
> safely upgrade to adjacent major versions".
>
> The difficulty we face with 3.0 is that it has made many contributors very
> wary of pre 4.0 code and with good reason. Your point about conservative
> users upgrading later in a cycle resonates Benedict, and reflects on the
> confidence we should or should not have in 3.11. I think it's also
> important to realize that many cluster upgrades can take months, so it's
> not a transient exposure to unknowns in a release.
>
> I propose the following compromise:
>
> 1. For 4.0 GA, we consider the following upgrade paths "tested and
> supported": 2.1 → 3.0 → 3.11 → 4.0, and 2.1 → 3.0 → 4.0
> 2. For all subsequent major releases, we test and officially support only
> 1 major back
> 3. Any contributor can optionally meet whatever bar we set for "tested and
> supported" to allow leapfrogging versions, but we won't constrain GA on
> that.
>
> We have to pay down our debt right now, but if we have to continue to do
> this in the future we're not learning from our mistakes.
>
> Speaking for DataStax, we don't have enough resources to work through the
> new testing work on 40_quality_test, the defects that David is surfacing
> like crazy (well done!), and validating 2 major upgrade paths. If you and a
> set of contributors could take on the 3.0 → 4.0 path Benedict, that'd be a
> great help. I also assume we could all collaborate on the tooling / infra /
> approaches we use for this validation so it wouldn't be a complete re-work.
>
> On Fri, Oct 09, 2020 at 11:02 AM, Benedict Elliott Smith < benedict@
> apache.org> wrote:
>
> Since email is very unclear and context gets lost, I'm personally OK with
> officially supporting all of these upgrade paths, but the spectre was
> raised that this might lead to lost labour due to an increased support
> burden. My view is that 3.0->4.0 is probably a safer upgrade path for users
> and as a result a lower support cost to the project, so I would be happy to
> deprecate 3.0->3.11 if this helps alleviate the concerns of others that
> this would be costly to the project. Alternatively, if we want to support
> both but some feel 3.0->4.0 is burdensome, I would be happy to focus on
> 3.0->4.0 while they focus on the paths I would be happy to deprecate.
>
> On 09/10/2020, 15:49, "Benedict Elliott Smith" <be...@apache.org>
> wrote:
>
> Yeah, and perhaps even drop 2.1 (2.2) -> 3.11 when 4.0 appears.
>
> I think there's anyway a big difference between supported and encouraged.
> I think we should encourage 2.1->3.0->4.0, while maintaining support for
> 2.2->3.0 and 3.0->3.11 for critical bugs only, and 3.11->4.0 in the normal
> way given the userbase that is already on 3.11.
>
> we can expect it to be *stable enough to upgrade through*
>
> I don't know that this is true at all. Most bugs are not found by the
> general userbase, and the most conservative (hence most likely to spot
> problems on upgrade) are generally very late to the party. 2.1(2.2)->3.0 is
> still discovering bugs today, many years after this metric was passed for
> 3.0 - largely as the more sophisticated users upgrade.
>
> On 09/10/2020, 15:40, "Marcus Eriksson" <ma...@apache.org> wrote:
>
> My suggestion for "supported" upgrade paths would be;
>
> 2.1 (2.2) -> 3.0 -> 4.0
> 2.1 (2.2) -> 3.11 -> 4.0
>
> and drop support for 3.0 -> 3.11 when we release 4.0
>
> /Marcus
>
> On 9 October 2020 at 16:12:12, Joshua McKenzie (jmckenzie@apache.org)
> wrote:
>
> Some data that I believe is relevant here.
>
> Numerically it's safe to assume there's over 10,000 ASF C* clusters out in
> the world (5,500 in China alone). In surveys (both informal polling and
> primary research), at least 1/3rd of folks are running the 3.X latest if I
> recall correctly.
>
> Basic conclusions we can draw from these data points:
> 1) There are thousands of clusters running some form of post 3.0, so we
> can expect it to be *stable enough to upgrade through*
> 2) We have to support at least 3.11 → 4.0
>
> If 1/3rd of our users are running 2.1, 1/3rd 3.0, and 1/3rd 3.11
> (hand-waving, probably more in the 25 vs. 40 etc but splitting hairs),
> there's clearly a significant value-add in usability of skipping majors
> (3.0->4.0). Depending on how we define "done" and "supported" for upgrade
> testing, this will represent a significant development burden.
>
> From a *functional MVP* perspective on what upgrade paths we need to
> support, the absolute minimum would be 2.1 → 3.0 → 3.11 → 4.0
>
> If anyone wants to step in and officially support the 3.0 → 4.0 line,
> that's fantastic both for the project community and for users. But as far
> as basic table stakes, I can't think of a logical reason 3.0 → 4.0 as an
> upgraded path should be considered a blocker for releasing 4.0 GA.
>
> On Fri, Oct 09, 2020 at 9:53 AM, Mick Semb Wever wrote:
>
> At The Last Pickle we have always recommended avoiding 3.0, including
> upgrading from 2.2 directly to 3.11.
> We (now DataStax) will continue to recommend that folk upgrade to the
> latest 3.11 before upgrading to 4.0.
>
> To clarify that^, if it wasn't obvious, I wasn't making a statement about
> DataStax at at large, but about those of us at TLP and now the team
> providing the consulting for Apache Cassandra from DataStax.
>
> --------------------------------------------------------------------- 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
>
> --------------------------------------------------------------------- To
> unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org For additional
> commands, e-mail: dev-help@cassandra.apache.org
>
Re: Supported upgrade path for 4.0
Posted by Benedict Elliott Smith <be...@apache.org>.
There is a sizeable cohort of us who I expect to be primarily focused on 3.0->4.0, so if you have a cohort focusing primarily on 3.11->4.0 I think we'll be in good shape.
> For all subsequent major releases, we test and officially support only 1 major back
I think we should wait to see what happens before committing ourselves to something like this - things like release cadence etc will matter a lot. That is *definitely* not to say that I disagree with you, just that I think more project future-context is needed to make a decision like this. I expect we'll have lots more fun (hopefully positive) conversations around topics like this in the coming year, as I have no doubt we all want to evolve our approach to releases, and there's no knowing what we'll end up deciding (we have done some crazy things in the past __ ).
On 09/10/2020, 16:46, "Joshua McKenzie" <jm...@apache.org> wrote:
I think it's a clean and simple heuristic for the project to say "you can
safely upgrade to adjacent major versions".
The difficulty we face with 3.0 is that it has made many contributors very
wary of pre 4.0 code and with good reason. Your point about conservative
users upgrading later in a cycle resonates Benedict, and reflects on the
confidence we should or should not have in 3.11. I think it's also
important to realize that many cluster upgrades can take months, so it's
not a transient exposure to unknowns in a release.
I propose the following compromise:
1. For 4.0 GA, we consider the following upgrade paths "tested and
supported": 2.1 → 3.0 → 3.11 → 4.0, and 2.1 → 3.0 → 4.0
2. For all subsequent major releases, we test and officially support
only 1 major back
3. Any contributor can optionally meet whatever bar we set for "tested
and supported" to allow leapfrogging versions, but we won't constrain GA on
that.
We have to pay down our debt right now, but if we have to continue to do
this in the future we're not learning from our mistakes.
Speaking for DataStax, we don't have enough resources to work through the
new testing work on 40_quality_test, the defects that David is surfacing
like crazy (well done!), and validating 2 major upgrade paths. If you and a
set of contributors could take on the 3.0 → 4.0 path Benedict, that'd be a
great help. I also assume we could all collaborate on the tooling / infra /
approaches we use for this validation so it wouldn't be a complete re-work.
On Fri, Oct 09, 2020 at 11:02 AM, Benedict Elliott Smith <
benedict@apache.org> wrote:
> Since email is very unclear and context gets lost, I'm personally OK with
> officially supporting all of these upgrade paths, but the spectre was
> raised that this might lead to lost labour due to an increased support
> burden. My view is that 3.0->4.0 is probably a safer upgrade path for users
> and as a result a lower support cost to the project, so I would be happy to
> deprecate 3.0->3.11 if this helps alleviate the concerns of others that
> this would be costly to the project. Alternatively, if we want to support
> both but some feel 3.0->4.0 is burdensome, I would be happy to focus on
> 3.0->4.0 while they focus on the paths I would be happy to deprecate.
>
> On 09/10/2020, 15:49, "Benedict Elliott Smith" <be...@apache.org>
> wrote:
>
> Yeah, and perhaps even drop 2.1 (2.2) -> 3.11 when 4.0 appears.
>
> I think there's anyway a big difference between supported and encouraged.
> I think we should encourage 2.1->3.0->4.0, while maintaining support for
> 2.2->3.0 and 3.0->3.11 for critical bugs only, and 3.11->4.0 in the normal
> way given the userbase that is already on 3.11.
>
> we can expect it to be *stable enough to upgrade through*
>
> I don't know that this is true at all. Most bugs are not found by the
> general userbase, and the most conservative (hence most likely to spot
> problems on upgrade) are generally very late to the party. 2.1(2.2)->3.0 is
> still discovering bugs today, many years after this metric was passed for
> 3.0 - largely as the more sophisticated users upgrade.
>
> On 09/10/2020, 15:40, "Marcus Eriksson" <ma...@apache.org> wrote:
>
> My suggestion for "supported" upgrade paths would be;
>
> 2.1 (2.2) -> 3.0 -> 4.0
> 2.1 (2.2) -> 3.11 -> 4.0
>
> and drop support for 3.0 -> 3.11 when we release 4.0
>
> /Marcus
>
> On 9 October 2020 at 16:12:12, Joshua McKenzie (jmckenzie@apache.org)
> wrote:
>
> Some data that I believe is relevant here.
>
> Numerically it's safe to assume there's over 10,000 ASF C* clusters out in
> the world (5,500 in China alone). In surveys (both informal polling and
> primary research), at least 1/3rd of folks are running the 3.X latest if I
> recall correctly.
>
> Basic conclusions we can draw from these data points:
> 1) There are thousands of clusters running some form of post 3.0, so we
> can expect it to be *stable enough to upgrade through*
> 2) We have to support at least 3.11 → 4.0
>
> If 1/3rd of our users are running 2.1, 1/3rd 3.0, and 1/3rd 3.11
> (hand-waving, probably more in the 25 vs. 40 etc but splitting hairs),
> there's clearly a significant value-add in usability of skipping majors
> (3.0->4.0). Depending on how we define "done" and "supported" for upgrade
> testing, this will represent a significant development burden.
>
> From a *functional MVP* perspective on what upgrade paths we need to
> support, the absolute minimum would be 2.1 → 3.0 → 3.11 → 4.0
>
> If anyone wants to step in and officially support the 3.0 → 4.0 line,
> that's fantastic both for the project community and for users. But as far
> as basic table stakes, I can't think of a logical reason 3.0 → 4.0 as an
> upgraded path should be considered a blocker for releasing 4.0 GA.
>
> On Fri, Oct 09, 2020 at 9:53 AM, Mick Semb Wever wrote:
>
> At The Last Pickle we have always recommended avoiding 3.0, including
> upgrading from 2.2 directly to 3.11.
> We (now DataStax) will continue to recommend that folk upgrade to the
> latest 3.11 before upgrading to 4.0.
>
> To clarify that^, if it wasn't obvious, I wasn't making a statement about
> DataStax at at large, but about those of us at TLP and now the team
> providing the consulting for Apache Cassandra from DataStax.
>
> --------------------------------------------------------------------- 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
For additional commands, e-mail: dev-help@cassandra.apache.org
Re: Supported upgrade path for 4.0
Posted by Joshua McKenzie <jm...@apache.org>.
I think it's a clean and simple heuristic for the project to say "you can
safely upgrade to adjacent major versions".
The difficulty we face with 3.0 is that it has made many contributors very
wary of pre 4.0 code and with good reason. Your point about conservative
users upgrading later in a cycle resonates Benedict, and reflects on the
confidence we should or should not have in 3.11. I think it's also
important to realize that many cluster upgrades can take months, so it's
not a transient exposure to unknowns in a release.
I propose the following compromise:
1. For 4.0 GA, we consider the following upgrade paths "tested and
supported": 2.1 → 3.0 → 3.11 → 4.0, and 2.1 → 3.0 → 4.0
2. For all subsequent major releases, we test and officially support
only 1 major back
3. Any contributor can optionally meet whatever bar we set for "tested
and supported" to allow leapfrogging versions, but we won't constrain GA on
that.
We have to pay down our debt right now, but if we have to continue to do
this in the future we're not learning from our mistakes.
Speaking for DataStax, we don't have enough resources to work through the
new testing work on 40_quality_test, the defects that David is surfacing
like crazy (well done!), and validating 2 major upgrade paths. If you and a
set of contributors could take on the 3.0 → 4.0 path Benedict, that'd be a
great help. I also assume we could all collaborate on the tooling / infra /
approaches we use for this validation so it wouldn't be a complete re-work.
On Fri, Oct 09, 2020 at 11:02 AM, Benedict Elliott Smith <
benedict@apache.org> wrote:
> Since email is very unclear and context gets lost, I'm personally OK with
> officially supporting all of these upgrade paths, but the spectre was
> raised that this might lead to lost labour due to an increased support
> burden. My view is that 3.0->4.0 is probably a safer upgrade path for users
> and as a result a lower support cost to the project, so I would be happy to
> deprecate 3.0->3.11 if this helps alleviate the concerns of others that
> this would be costly to the project. Alternatively, if we want to support
> both but some feel 3.0->4.0 is burdensome, I would be happy to focus on
> 3.0->4.0 while they focus on the paths I would be happy to deprecate.
>
> On 09/10/2020, 15:49, "Benedict Elliott Smith" <be...@apache.org>
> wrote:
>
> Yeah, and perhaps even drop 2.1 (2.2) -> 3.11 when 4.0 appears.
>
> I think there's anyway a big difference between supported and encouraged.
> I think we should encourage 2.1->3.0->4.0, while maintaining support for
> 2.2->3.0 and 3.0->3.11 for critical bugs only, and 3.11->4.0 in the normal
> way given the userbase that is already on 3.11.
>
> we can expect it to be *stable enough to upgrade through*
>
> I don't know that this is true at all. Most bugs are not found by the
> general userbase, and the most conservative (hence most likely to spot
> problems on upgrade) are generally very late to the party. 2.1(2.2)->3.0 is
> still discovering bugs today, many years after this metric was passed for
> 3.0 - largely as the more sophisticated users upgrade.
>
> On 09/10/2020, 15:40, "Marcus Eriksson" <ma...@apache.org> wrote:
>
> My suggestion for "supported" upgrade paths would be;
>
> 2.1 (2.2) -> 3.0 -> 4.0
> 2.1 (2.2) -> 3.11 -> 4.0
>
> and drop support for 3.0 -> 3.11 when we release 4.0
>
> /Marcus
>
> On 9 October 2020 at 16:12:12, Joshua McKenzie (jmckenzie@apache.org)
> wrote:
>
> Some data that I believe is relevant here.
>
> Numerically it's safe to assume there's over 10,000 ASF C* clusters out in
> the world (5,500 in China alone). In surveys (both informal polling and
> primary research), at least 1/3rd of folks are running the 3.X latest if I
> recall correctly.
>
> Basic conclusions we can draw from these data points:
> 1) There are thousands of clusters running some form of post 3.0, so we
> can expect it to be *stable enough to upgrade through*
> 2) We have to support at least 3.11 → 4.0
>
> If 1/3rd of our users are running 2.1, 1/3rd 3.0, and 1/3rd 3.11
> (hand-waving, probably more in the 25 vs. 40 etc but splitting hairs),
> there's clearly a significant value-add in usability of skipping majors
> (3.0->4.0). Depending on how we define "done" and "supported" for upgrade
> testing, this will represent a significant development burden.
>
> From a *functional MVP* perspective on what upgrade paths we need to
> support, the absolute minimum would be 2.1 → 3.0 → 3.11 → 4.0
>
> If anyone wants to step in and officially support the 3.0 → 4.0 line,
> that's fantastic both for the project community and for users. But as far
> as basic table stakes, I can't think of a logical reason 3.0 → 4.0 as an
> upgraded path should be considered a blocker for releasing 4.0 GA.
>
> On Fri, Oct 09, 2020 at 9:53 AM, Mick Semb Wever wrote:
>
> At The Last Pickle we have always recommended avoiding 3.0, including
> upgrading from 2.2 directly to 3.11.
> We (now DataStax) will continue to recommend that folk upgrade to the
> latest 3.11 before upgrading to 4.0.
>
> To clarify that^, if it wasn't obvious, I wasn't making a statement about
> DataStax at at large, but about those of us at TLP and now the team
> providing the consulting for Apache Cassandra from DataStax.
>
> --------------------------------------------------------------------- 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
>
Re: Supported upgrade path for 4.0
Posted by Benedict Elliott Smith <be...@apache.org>.
Since email is very unclear and context gets lost, I'm personally OK with officially supporting all of these upgrade paths, but the spectre was raised that this might lead to lost labour due to an increased support burden. My view is that 3.0->4.0 is probably a safer upgrade path for users and as a result a lower support cost to the project, so I would be happy to deprecate 3.0->3.11 if this helps alleviate the concerns of others that this would be costly to the project. Alternatively, if we want to support both but some feel 3.0->4.0 is burdensome, I would be happy to focus on 3.0->4.0 while they focus on the paths I would be happy to deprecate.
On 09/10/2020, 15:49, "Benedict Elliott Smith" <be...@apache.org> wrote:
Yeah, and perhaps even drop 2.1 (2.2) -> 3.11 when 4.0 appears.
I think there's anyway a big difference between supported and encouraged. I think we should encourage 2.1->3.0->4.0, while maintaining support for 2.2->3.0 and 3.0->3.11 for critical bugs only, and 3.11->4.0 in the normal way given the userbase that is already on 3.11.
> we can expect it to be *stable enough to upgrade through*
I don't know that this is true at all. Most bugs are not found by the general userbase, and the most conservative (hence most likely to spot problems on upgrade) are generally very late to the party. 2.1(2.2)->3.0 is still discovering bugs today, many years after this metric was passed for 3.0 - largely as the more sophisticated users upgrade.
On 09/10/2020, 15:40, "Marcus Eriksson" <ma...@apache.org> wrote:
My suggestion for "supported" upgrade paths would be;
2.1 (2.2) -> 3.0 -> 4.0
2.1 (2.2) -> 3.11 -> 4.0
and drop support for 3.0 -> 3.11 when we release 4.0
/Marcus
On 9 October 2020 at 16:12:12, Joshua McKenzie (jmckenzie@apache.org) wrote:
> Some data that I believe is relevant here.
>
> Numerically it's safe to assume there's over 10,000 ASF C* clusters out in
> the world (5,500 in China alone). In surveys (both informal polling and
> primary research), at least 1/3rd of folks are running the 3.X latest if I
> recall correctly.
>
> Basic conclusions we can draw from these data points:
> 1) There are thousands of clusters running some form of post 3.0, so we can
> expect it to be *stable enough to upgrade through*
> 2) We have to support at least 3.11 → 4.0
>
> If 1/3rd of our users are running 2.1, 1/3rd 3.0, and 1/3rd 3.11
> (hand-waving, probably more in the 25 vs. 40 etc but splitting hairs),
> there's clearly a significant value-add in usability of skipping majors
> (3.0->4.0). Depending on how we define "done" and "supported" for upgrade
> testing, this will represent a significant development burden.
>
> From a *functional MVP* perspective on what upgrade paths we need to
> support, the absolute minimum would be 2.1 → 3.0 → 3.11 → 4.0
>
> If anyone wants to step in and officially support the 3.0 → 4.0 line,
> that's fantastic both for the project community and for users. But as far
> as basic table stakes, I can't think of a logical reason 3.0 → 4.0 as an
> upgraded path should be considered a blocker for releasing 4.0 GA.
>
>
>
> On Fri, Oct 09, 2020 at 9:53 AM, Mick Semb Wever wrote:
>
> > At The Last Pickle we have always recommended avoiding 3.0, including
> > upgrading from 2.2 directly to 3.11.
> > We (now DataStax) will continue to recommend that folk upgrade to the
> > latest 3.11 before upgrading to 4.0.
> >
> > To clarify that^, if it wasn't obvious, I wasn't making a statement about
> > DataStax at at large, but about those of us at TLP and now the team
> > providing the consulting for Apache Cassandra from DataStax.
> >
>
---------------------------------------------------------------------
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
Re: Supported upgrade path for 4.0
Posted by Benedict Elliott Smith <be...@apache.org>.
Yeah, and perhaps even drop 2.1 (2.2) -> 3.11 when 4.0 appears.
I think there's anyway a big difference between supported and encouraged. I think we should encourage 2.1->3.0->4.0, while maintaining support for 2.2->3.0 and 3.0->3.11 for critical bugs only, and 3.11->4.0 in the normal way given the userbase that is already on 3.11.
> we can expect it to be *stable enough to upgrade through*
I don't know that this is true at all. Most bugs are not found by the general userbase, and the most conservative (hence most likely to spot problems on upgrade) are generally very late to the party. 2.1(2.2)->3.0 is still discovering bugs today, many years after this metric was passed for 3.0 - largely as the more sophisticated users upgrade.
On 09/10/2020, 15:40, "Marcus Eriksson" <ma...@apache.org> wrote:
My suggestion for "supported" upgrade paths would be;
2.1 (2.2) -> 3.0 -> 4.0
2.1 (2.2) -> 3.11 -> 4.0
and drop support for 3.0 -> 3.11 when we release 4.0
/Marcus
On 9 October 2020 at 16:12:12, Joshua McKenzie (jmckenzie@apache.org) wrote:
> Some data that I believe is relevant here.
>
> Numerically it's safe to assume there's over 10,000 ASF C* clusters out in
> the world (5,500 in China alone). In surveys (both informal polling and
> primary research), at least 1/3rd of folks are running the 3.X latest if I
> recall correctly.
>
> Basic conclusions we can draw from these data points:
> 1) There are thousands of clusters running some form of post 3.0, so we can
> expect it to be *stable enough to upgrade through*
> 2) We have to support at least 3.11 → 4.0
>
> If 1/3rd of our users are running 2.1, 1/3rd 3.0, and 1/3rd 3.11
> (hand-waving, probably more in the 25 vs. 40 etc but splitting hairs),
> there's clearly a significant value-add in usability of skipping majors
> (3.0->4.0). Depending on how we define "done" and "supported" for upgrade
> testing, this will represent a significant development burden.
>
> From a *functional MVP* perspective on what upgrade paths we need to
> support, the absolute minimum would be 2.1 → 3.0 → 3.11 → 4.0
>
> If anyone wants to step in and officially support the 3.0 → 4.0 line,
> that's fantastic both for the project community and for users. But as far
> as basic table stakes, I can't think of a logical reason 3.0 → 4.0 as an
> upgraded path should be considered a blocker for releasing 4.0 GA.
>
>
>
> On Fri, Oct 09, 2020 at 9:53 AM, Mick Semb Wever wrote:
>
> > At The Last Pickle we have always recommended avoiding 3.0, including
> > upgrading from 2.2 directly to 3.11.
> > We (now DataStax) will continue to recommend that folk upgrade to the
> > latest 3.11 before upgrading to 4.0.
> >
> > To clarify that^, if it wasn't obvious, I wasn't making a statement about
> > DataStax at at large, but about those of us at TLP and now the team
> > providing the consulting for Apache Cassandra from DataStax.
> >
>
---------------------------------------------------------------------
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: Supported upgrade path for 4.0
Posted by Marcus Eriksson <ma...@apache.org>.
My suggestion for "supported" upgrade paths would be;
2.1 (2.2) -> 3.0 -> 4.0
2.1 (2.2) -> 3.11 -> 4.0
and drop support for 3.0 -> 3.11 when we release 4.0
/Marcus
On 9 October 2020 at 16:12:12, Joshua McKenzie (jmckenzie@apache.org) wrote:
> Some data that I believe is relevant here.
>
> Numerically it's safe to assume there's over 10,000 ASF C* clusters out in
> the world (5,500 in China alone). In surveys (both informal polling and
> primary research), at least 1/3rd of folks are running the 3.X latest if I
> recall correctly.
>
> Basic conclusions we can draw from these data points:
> 1) There are thousands of clusters running some form of post 3.0, so we can
> expect it to be *stable enough to upgrade through*
> 2) We have to support at least 3.11 → 4.0
>
> If 1/3rd of our users are running 2.1, 1/3rd 3.0, and 1/3rd 3.11
> (hand-waving, probably more in the 25 vs. 40 etc but splitting hairs),
> there's clearly a significant value-add in usability of skipping majors
> (3.0->4.0). Depending on how we define "done" and "supported" for upgrade
> testing, this will represent a significant development burden.
>
> From a *functional MVP* perspective on what upgrade paths we need to
> support, the absolute minimum would be 2.1 → 3.0 → 3.11 → 4.0
>
> If anyone wants to step in and officially support the 3.0 → 4.0 line,
> that's fantastic both for the project community and for users. But as far
> as basic table stakes, I can't think of a logical reason 3.0 → 4.0 as an
> upgraded path should be considered a blocker for releasing 4.0 GA.
>
>
>
> On Fri, Oct 09, 2020 at 9:53 AM, Mick Semb Wever wrote:
>
> > At The Last Pickle we have always recommended avoiding 3.0, including
> > upgrading from 2.2 directly to 3.11.
> > We (now DataStax) will continue to recommend that folk upgrade to the
> > latest 3.11 before upgrading to 4.0.
> >
> > To clarify that^, if it wasn't obvious, I wasn't making a statement about
> > DataStax at at large, but about those of us at TLP and now the team
> > providing the consulting for Apache Cassandra from DataStax.
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
For additional commands, e-mail: dev-help@cassandra.apache.org
Re: Supported upgrade path for 4.0
Posted by Joshua McKenzie <jm...@apache.org>.
Some data that I believe is relevant here.
Numerically it's safe to assume there's over 10,000 ASF C* clusters out in
the world (5,500 in China alone). In surveys (both informal polling and
primary research), at least 1/3rd of folks are running the 3.X latest if I
recall correctly.
Basic conclusions we can draw from these data points:
1) There are thousands of clusters running some form of post 3.0, so we can
expect it to be *stable enough to upgrade through*
2) We have to support at least 3.11 → 4.0
If 1/3rd of our users are running 2.1, 1/3rd 3.0, and 1/3rd 3.11
(hand-waving, probably more in the 25 vs. 40 etc but splitting hairs),
there's clearly a significant value-add in usability of skipping majors
(3.0->4.0). Depending on how we define "done" and "supported" for upgrade
testing, this will represent a significant development burden.
From a *functional MVP* perspective on what upgrade paths we need to
support, the absolute minimum would be 2.1 → 3.0 → 3.11 → 4.0
If anyone wants to step in and officially support the 3.0 → 4.0 line,
that's fantastic both for the project community and for users. But as far
as basic table stakes, I can't think of a logical reason 3.0 → 4.0 as an
upgraded path should be considered a blocker for releasing 4.0 GA.
On Fri, Oct 09, 2020 at 9:53 AM, Mick Semb Wever <mc...@apache.org> wrote:
> At The Last Pickle we have always recommended avoiding 3.0, including
> upgrading from 2.2 directly to 3.11.
> We (now DataStax) will continue to recommend that folk upgrade to the
> latest 3.11 before upgrading to 4.0.
>
> To clarify that^, if it wasn't obvious, I wasn't making a statement about
> DataStax at at large, but about those of us at TLP and now the team
> providing the consulting for Apache Cassandra from DataStax.
>
Re: Supported upgrade path for 4.0
Posted by Mick Semb Wever <mc...@apache.org>.
> At The Last Pickle we have always recommended avoiding 3.0, including
> upgrading from 2.2 directly to 3.11.
> We (now DataStax) will continue to recommend that folk upgrade to the
> latest 3.11 before upgrading to 4.0.
>
To clarify that^, if it wasn't obvious, I wasn't making a statement about
DataStax at at large, but about those of us at TLP and now the team
providing the consulting for Apache Cassandra from DataStax.
Re: Supported upgrade path for 4.0
Posted by Marcus Eriksson <ma...@apache.org>.
On 9 October 2020 at 10:23:02, Benedict Elliott Smith (benedict@apache.org) wrote:
> I would personally prefer the community to officially recommend skipping 3.11 to users
> that have not yet upgraded, as 3.0 and 4.0 have each had much more attention given to them
> over the past several years. This would naturally lead to fewer issues filed for 3.0->3.11
> and 3.11->4.0, as fewer users take this upgrade path.
+1
Upgrades are painful even without hitting any issues so avoiding one upgrade should help users.
/Marcus
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
For additional commands, e-mail: dev-help@cassandra.apache.org
Re: Supported upgrade path for 4.0
Posted by Erick Ramirez <er...@datastax.com>.
>
> Perhaps if others want to explicitly encourage the 3.0->3.11->4.0 upgrade
> path, we can split our resources accordingly?
>
Would it be necessary to go from 3.0 to 3.11 on the way to 4.0? I didn't
think that was required.
Re: Supported upgrade path for 4.0
Posted by Mick Semb Wever <mc...@apache.org>.
>
> > Dropping support for upgrading from 3.0 to 3.11
>
> Nobody is proposing dropping support, but my personal preference would be
> to officially endorse encouraging users to go directly 3.0->4.0, which
> would reduce the support burden for 3.0->3.11 and 3.11->4.0, as many users
> will skip 3.11 entirely if we encourage them to do so. If you would prefer
> to officially encourage 3.0->3.11->4.0, and I would prefer to officially
> encourage 3.0->4.0, it seems reasonable to split the support burden for the
> paths we want to officially endorse, and endorse both?
How does one go about doing that when we must still support
- upgrading from 2.2/3.0 to 3.11, and
- upgrading from 3.11 to 4.0
And what do we mean by "officially supported upgrade paths"? Is it that we
will accept fixes for it, or that we are committed to fixing it for you.
If some folk are committing to helping users fix bugs with 3.0->4.0
upgrades, and others are committing to help users fix bugs with 3.11->4.0,
then it sounds like we need to support both and that is a good thing.
Re: Supported upgrade path for 4.0
Posted by Benedict Elliott Smith <be...@apache.org>.
> Would it be necessary to go from 3.0 to 3.11 on the way to 4.0? I didn't
> think that was required.
That's what's being discussed, and Mick is proposing requiring it officially, to reduce support burden.
> What has been fixed in 3.0 that hasn't been merged into 3.11 ?
Nothing that I'm aware of, but how many bugs are unique to 3.11 that have not been discovered?
> Dropping support for upgrading from 3.0 to 3.11
Nobody is proposing dropping support, but my personal preference would be to officially endorse encouraging users to go directly 3.0->4.0, which would reduce the support burden for 3.0->3.11 and 3.11->4.0, as many users will skip 3.11 entirely if we encourage them to do so. If you would prefer to officially encourage 3.0->3.11->4.0, and I would prefer to officially encourage 3.0->4.0, it seems reasonable to split the support burden for the paths we want to officially endorse, and endorse both?
On 09/10/2020, 09:47, "Mick Semb Wever" <mc...@apache.org> wrote:
I would personally prefer the community to officially recommend skipping
> 3.11 to users that have not yet upgraded, as 3.0 and 4.0 have each had much
> more attention given to them over the past several years.
What has been fixed in 3.0 that hasn't been merged into 3.11 ?
Dropping support for upgrading from 3.0 to 3.11 would be a weird deviation
from the general practice of being able to upgrade from one major version
to the next.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
For additional commands, e-mail: dev-help@cassandra.apache.org
Re: Supported upgrade path for 4.0
Posted by Mick Semb Wever <mc...@apache.org>.
I would personally prefer the community to officially recommend skipping
> 3.11 to users that have not yet upgraded, as 3.0 and 4.0 have each had much
> more attention given to them over the past several years.
What has been fixed in 3.0 that hasn't been merged into 3.11 ?
Dropping support for upgrading from 3.0 to 3.11 would be a weird deviation
from the general practice of being able to upgrade from one major version
to the next.
Re: Supported upgrade path for 4.0
Posted by Benedict Elliott Smith <be...@apache.org>.
I would personally prefer the community to officially recommend skipping 3.11 to users that have not yet upgraded, as 3.0 and 4.0 have each had much more attention given to them over the past several years. This would naturally lead to fewer issues filed for 3.0->3.11 and 3.11->4.0, as fewer users take this upgrade path.
Perhaps if others want to explicitly encourage the 3.0->3.11->4.0 upgrade path, we can split our resources accordingly?
On 09/10/2020, 07:49, "Mick Semb Wever" <mc...@apache.org> wrote:
Anyone have an opinion here or any formal prior art for us to build on?
>
Maybe this question should be more phrased as to which upgrade paths each
individual has time in helping and fixing users out?
If you are voting for official support for the 3.0 upgrade path then that
should imply you are putting up your hand in helping
provide that official support in the community. (Whatever officially
supported is deemed to be)
I am only for supporting upgrades from latest 3.11. It makes life a lot
simpler for all of us, and helps focus our community time on CEPs and
otherwise maintaining our supported branches.
At The Last Pickle we have always recommended avoiding 3.0, including
upgrading from 2.2 directly to 3.11.
We (now DataStax) will continue to recommend that folk upgrade to the
latest 3.11 before upgrading to 4.0.
regards,
Mick
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
For additional commands, e-mail: dev-help@cassandra.apache.org
Re: Supported upgrade path for 4.0
Posted by Mick Semb Wever <mc...@apache.org>.
Anyone have an opinion here or any formal prior art for us to build on?
>
Maybe this question should be more phrased as to which upgrade paths each
individual has time in helping and fixing users out?
If you are voting for official support for the 3.0 upgrade path then that
should imply you are putting up your hand in helping
provide that official support in the community. (Whatever officially
supported is deemed to be)
I am only for supporting upgrades from latest 3.11. It makes life a lot
simpler for all of us, and helps focus our community time on CEPs and
otherwise maintaining our supported branches.
At The Last Pickle we have always recommended avoiding 3.0, including
upgrading from 2.2 directly to 3.11.
We (now DataStax) will continue to recommend that folk upgrade to the
latest 3.11 before upgrading to 4.0.
regards,
Mick