issues.apache.org/jira/browse/CASSANDRA-18300 epic to track
> tickets related to the downgradability. Please add the tickets you are
> aware of.
>
> thanks
> - - -- --- - -
> Jacek Lewandowski
>
>
> czw., 23 lut 2023 o 17:47 Benedict napisał(a):
A bit of organization - I've created
https://issues.apache.org/jira/browse/CASSANDRA-18300 epic to track tickets
related to the downgradability. Please add the tickets you are aware of.
thanks
- - -- --- - -
Jacek Lewandowski
czw., 23 lut 2023 o 17:47 Benedict napisał
Either way, it feels like this has become much more of a big deal than it needed to.I would prefer the pending patches to avoid breaking compatibility, as I think they can do it easily. But, if we agree to block release until we can double back to fix it with versioned writing (which I agree with
Right. So I'm speculating everyone else who worked on a patch that breaks
compatibility has been working under the mindset "I'll just put this behind
the same switch". Or something more vague / even less correct, such as
assuming that tries would become the default immediately.
At least in my
I don’t think there’s anything about a new format that requires a version bump, but I could be missing something.We have to have a switch to enable tries already don’t we? I’m pretty sure we haven’t talked about switching the default format?On 23 Feb 2023, at 12:12, Henrik Ingo wrote:On Thu, Feb
On Thu, Feb 23, 2023 at 11:57 AM Benedict wrote:
> Can somebody explain to me why this is being fought tooth and nail, when
> the work involved is absolutely minimal?
>
>
I don't know how each individual has been thinking about this, but it seems
to me just looking at all the tasks that at least
ds?
>>
>>
>> On 23 Feb 2023, at 09:45, Benjamin Lerer wrote:
>>
>>
>>
>>> Can somebody explain to me what is so burdensome, that we seem to be
>>> spending longer debating it than it would take to implement the necessary
>>> changes?
&
y explain to me what is so burdensome, that we seem to be
>> spending longer debating it than it would take to implement the necessary
>> changes?
>
>
> I believe that we all agree on the outcome. Everybody wants
> downgradability. The issue is on the path to get there.
>
&
. Everybody wants downgradability. The issue is on the path to get there.As far as I am concerned, I would like to see a proper solution and as Jeff suggested the equivalent of the upgrade tests as gatekeepers. Having everybody trying to enforce it on his own way will only lead to a poor result in my
>
> Can somebody explain to me what is so burdensome, that we seem to be
> spending longer debating it than it would take to implement the necessary
> changes?
I believe that we all agree on the outcome. Everybody wants
downgradability. The issue is on the path to get there.
As
to X". Until we actually define and agree that this is a
>>> real goal with a concrete version where downgrade-ability becomes real, it
>>> feels like things are somewhat arbitrarily enforced, which is probably very
>>> frustrating for people trying to commit work/tickets.
>>
with a
>> concrete version where downgrade-ability becomes real, it feels like things
>> are somewhat arbitrarily enforced, which is probably very frustrating for
>> people trying to commit work/tickets.
>>
>> - Jeff
>>
>>
>>
>> On Mon, Feb 20, 2023
.
>
> - Jeff
>
>
>
> On Mon, Feb 20, 2023 at 11:48 AM Dinesh Joshi wrote:
>
>> I’m a big fan of maintaining backward compatibility. Downgradability
>> implies that we could potentially roll back an upgrade at any time. While I
>> don’t think we need
Those tickets mostly do not need to break compatibility, and it is pretty easy for them to avoid doing so without any additional facilities.Only the TTL ticket has an excuse, as it debatably needs to support a higher version under certain non-default config settings. However there are no
We have multiple tickets about to merge that introduce new on disk format
changes. I see no reason to block those indefinitely while we figure out how
to do the on disk format downgrade stuff.
-Jeremiah
> On Feb 22, 2023, at 3:12 PM, Benedict wrote:
>
> Ok I will be honest, I was fairly
Ok I will be honest, I was fairly sure we hadn’t yet broken downgrade - but I was wrong. CASSANDRA-18061 introduced a new column to a system table, which is a breaking change. But that’s it, as far as I can tell. I have run a downgrade test successfully after reverting that ticket, using the one
> why not implement backwards write compatibility?
+1 to this from a philosophical perspective. Keeping prior releases completely
in the dark about new release sstable formats is a clean approach, and we
should already have the code around to ser/deser the prior version's data on
the next
When people are serious about this requirement, they’ll build the downgrade equivalents of the upgrade tests and run them automatically, often, so people understand what the real gap is and when something new makes it break Until those tests exist, I think collectively we should all stop
> 1. Major SSTable changes should begin with forward-compatibility in a
prior release.
This requires "feature" changes, i.e. new non-trivial code for previous
patch releases. It also entails porting over any further format
modification.
Instead of this, in combination with your second point, why
Some interesting existing work on this subject is "Understanding and Detecting
Software Upgrade Failures in Distributed Systems" -
https://dl.acm.org/doi/10.1145/3477132.3483577, also summarized by Andrey
Satarin here:
gt;>
>> 1. Cassandra users must be able to abort and revert an upgrade to a new
>> version of the database that introduces a new major SSTable format.
>>
>> This reduces risk of upgrading to a build that also introduces a
>> non-data-format-related bug that is intolerable
to a build that also introduces a non-data-format-related bug that is intolerable. This goal does not specify a mechanism or downgrade target - just the "downgradability" goal.2. Where possible, Cassandra users should be able to opt into writing of a new major SSTable format.This reduces
format.This reduces risk of upgrading to a build that also introduces a non-data-format-related bug that is
intolerable. This goal does not specify a mechanism or downgrade target - just the "downgradability" goal.2. Where possible, Cassandra users should be able to opt into writing of a new majo
e up to date with new features as they are introduced. The moment that
> suite is in place, we can start having some confidence that we can enforce
> downgradability.
>
> Something like this will definitely catch incompatibilities in SSTable
> formats (such as the one in CASSANDRA
incompatible system schema changes among others, and at the same time rightfully ignore non-breaking changes such as modifications to the key cache serialization formats.Is downgradability in scope for 5.0? It is a feature like any other, and I don't see any difficulty adding it (with support for downgrade
downgradability.
Something like this will definitely catch incompatibilities in SSTable
formats (such as the one in CASSANDRA-17698 that I managed to miss during
review), but will also be able to identify incompatible system schema
changes among others, and at the same time rightfully ignore non
ort shifted and so incorrectly read." - this is a
>>> harder problem to solve than just versioning sstables and network
>>> protocols.
>>>
>>> Stepping back a bit, we have downgrade ability listed as a goal, but
>>> it's not (as far as I can tell) unive
etely say "this release can be downgraded to
>> X". Until we actually define and agree that this is a real goal with a
>> concrete version where downgrade-ability becomes real, it feels like things
>> are somewhat arbitrarily enforced, which is probably very frustrati
tually define and agree that this is a real goal with a
> concrete version where downgrade-ability becomes real, it feels like things
> are somewhat arbitrarily enforced, which is probably very frustrating for
> people trying to commit work/tickets.
>
> - Jeff
>
>
>
> On
ing to commit work/tickets.- JeffOn Mon, Feb 20, 2023 at 11:48 AM Dinesh Joshi <djo...@apache.org> wrote:I’m a big fan of maintaining backward compatibility. Downgradability implies that we could potentially roll back an upgrade at any time. While I don’t think we need to retain the ability to
nforced, which is probably very frustrating for people trying to commit work/tickets.- JeffOn Mon, Feb 20, 2023 at 11:48 AM Dinesh Joshi <djo...@apache.org> wrote:I’m a big fan of maintaining backward compatibility. Downgradability implies that we could potentially roll back an upgrade at any t
ike things
are somewhat arbitrarily enforced, which is probably very frustrating for
people trying to commit work/tickets.
- Jeff
On Mon, Feb 20, 2023 at 11:48 AM Dinesh Joshi wrote:
> I’m a big fan of maintaining backward compatibility. Downgradability
> implies that we could potentially rol
I’m a big fan of maintaining backward compatibility. Downgradability implies that we could potentially roll back an upgrade at any time. While I don’t think we need to retain the ability to downgrade in perpetuity it would be a good objective to maintain strict backward compatibility and therefore
ASSANDRA-18134
>> <https://issues.apache.org/jira/browse/CASSANDRA-18134>, and is
>> spreading into CASSANDRA-14277
>> <https://issues.apache.org/jira/browse/CASSANDRA-14227> and
>> CASSANDRA-17698 <https://issues.apache.org/jira/browse/CASSANDRA-17698>,
>
is in CASSANDRA-18134
> <https://issues.apache.org/jira/browse/CASSANDRA-18134>, and is spreading
> into CASSANDRA-14277
> <https://issues.apache.org/jira/browse/CASSANDRA-14227> and
> CASSANDRA-17698 <https://issues.apache.org/jira/browse/CASSANDRA-17698>,
> none of which is a
ch is a good place to discuss the topic seriously.
Downgradability is a worthy goal and is listed in the current roadmap. I
would like to open a discussion here on how it would be achieved.
My understanding of what has been suggested so far translates to:
- avoid changes to sstable formats;
- if
36 matches
Mail list logo
