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 fo
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 i
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 t
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 custom
> "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
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
This sounds eminently sensible to me.
On 09/10/2020, 19:42, "Joshua McKenzie" 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 t
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 w
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
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
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 a
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
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 (jmcken...@apache.org) wrote:
> Some data that I believe is relevant here.
>
> N
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 conclusi
> 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
>
> > 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
> 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 o
On 9 October 2020 at 10:23:02, Benedict Elliott Smith (bened...@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 sever
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
>
> 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.
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 us
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
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.late
+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 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, 20
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 wrote:
>
> Hi Josh,
>
> This is a really good question. I agree with David about making sure this
> is cle
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 simpl
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 vote
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
28 matches
Mail list logo
