Re: [DISCUSS] How to implement backward compatibility (CASSANDRA-17048)
Yes, I implemented that as mentioned above - cassandra.yaml option, disabled by default, description explaining the reason and consequences. - - -- --- - - Jacek Lewandowski On Wed, Oct 27, 2021 at 3:58 PM David Capwell wrote: > > should we let users enable the new uuid ids later when they are sure > they will not downgrade in the future? > > I strongly believe new features should be off by default and give a “good > enough” grace period before enabling by default (while still offering > support to disable). As long as this is disabled by default I am cool with > it. > > > On Oct 26, 2021, at 1:25 PM, Jacek Lewandowski < > lewandowski.ja...@gmail.com> wrote: > > > > Yes, those explanations sound very reasonable to me as well and I'll > push the implementation soon. > > > > Thank you guys > > > > On 2021/10/26 18:21:44, Joshua McKenzie wrote: > >> +1 to Benedict's perspective here. Supporting both sstable ID paradigms > >> should be relatively trivial and low cost to maintain going forward. > >> > >> On Tue, Oct 26, 2021 at 7:54 AM bened...@apache.org < > bened...@apache.org> > >> wrote: > >> > >>> I think it is probably acceptable to prevent downgrades once a new > feature > >>> is enabled, as the exposure risk is limited to that one feature. The > user > >>> can test the new version to ensure everything else works satisfactorily > >>> before committing to this one feature. > >>> > >>> A downgrade tool would also be possible to produce, but probably the > >>> additional utility is limited. > >>> > >>> I think this particular feature is probably easy enough to maintain as > >>> permanently optional, simply maintaining two system tables: one for > the old > >>> generation format, one for the new. So long as the user doesn’t use > the new > >>> format, it remains forever downgradeable. Though perhaps one day we may > >>> want to force users to migrate, I don’t think there’s any rush, and the > >>> important thing to avoid is providing users no version buffer to > escape new > >>> bugs – if a major version later we force upgrade, then they have a > whole > >>> range of major versions to downgrade to that still support this feature > >>> (but perhaps avoid some other new issue) > >>> > >>> > >>> > >>> From: Jacek Lewandowski > >>> Date: Tuesday, 26 October 2021 at 12:01 > >>> To: dev@cassandra.apache.org > >>> Subject: Re: [DISCUSS] How to implement backward compatibility > >>> (CASSANDRA-17048) > >>> Though, the user is unable to test the new feature without enabling > it. And > >>> when it is enabled, the user is unable to revert it. > >>> > >>> - - -- --- - - > >>> Jacek Lewandowski > >>> > >>> > >>> On Tue, Oct 26, 2021 at 12:54 PM Bowen Song > wrote: > >>> > >>>> Personally, I would prefer a transition period in which the new > feature > >>>> is not enabled by default. This not only makes version upgrading > easier, > >>>> it also allows the user to stay on the old behaviour if they > experience > >>>> any issue with the new feature (e.g.: bugs in the new feature, or edge > >>>> use cases / 3rd party tools depending on the old behaviour) until the > >>>> issue is resolved. > >>>> > >>>> On 26/10/2021 10:21, Jacek Lewandowski wrote: > >>>>> Hi, > >>>>> > >>>>> In short, we are discussing UUID based sstable generation identifiers > >>> in > >>>> https://issues.apache.org/jira/browse/CASSANDRA-17048. > >>>>> > >>>>> The question which somehow hold us is support for downgrading. Long > >>>> story short, when we generate new sstables with uuid based ids, they > are > >>>> not readable by older C* versions. > >>>>> > >>>>> 1. should we implement a downgrade tool? (it may be quite complex) > >>>>> 2. should we let users enable the new uuid ids later when they are > sure > >>>> they will not downgrade in the future? > >>>>> > >>>>> Thanks, > >>>>> Jacek > >>>>> > >>>>> > >>>>> > >>>>> - > >>>>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > >>>>> For additional commands, e-mail: dev-h...@cassandra.apache.org > >>>>> > >>>> > >>>> - > >>>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > >>>> For additional commands, e-mail: dev-h...@cassandra.apache.org > >>>> > >>>> > >>> > >> > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > > For additional commands, e-mail: dev-h...@cassandra.apache.org > > > > > - > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > For additional commands, e-mail: dev-h...@cassandra.apache.org > >
Re: [DISCUSS] How to implement backward compatibility (CASSANDRA-17048)
> should we let users enable the new uuid ids later when they are sure they > will not downgrade in the future? I strongly believe new features should be off by default and give a “good enough” grace period before enabling by default (while still offering support to disable). As long as this is disabled by default I am cool with it. > On Oct 26, 2021, at 1:25 PM, Jacek Lewandowski > wrote: > > Yes, those explanations sound very reasonable to me as well and I'll push the > implementation soon. > > Thank you guys > > On 2021/10/26 18:21:44, Joshua McKenzie wrote: >> +1 to Benedict's perspective here. Supporting both sstable ID paradigms >> should be relatively trivial and low cost to maintain going forward. >> >> On Tue, Oct 26, 2021 at 7:54 AM bened...@apache.org >> wrote: >> >>> I think it is probably acceptable to prevent downgrades once a new feature >>> is enabled, as the exposure risk is limited to that one feature. The user >>> can test the new version to ensure everything else works satisfactorily >>> before committing to this one feature. >>> >>> A downgrade tool would also be possible to produce, but probably the >>> additional utility is limited. >>> >>> I think this particular feature is probably easy enough to maintain as >>> permanently optional, simply maintaining two system tables: one for the old >>> generation format, one for the new. So long as the user doesn’t use the new >>> format, it remains forever downgradeable. Though perhaps one day we may >>> want to force users to migrate, I don’t think there’s any rush, and the >>> important thing to avoid is providing users no version buffer to escape new >>> bugs – if a major version later we force upgrade, then they have a whole >>> range of major versions to downgrade to that still support this feature >>> (but perhaps avoid some other new issue) >>> >>> >>> >>> From: Jacek Lewandowski >>> Date: Tuesday, 26 October 2021 at 12:01 >>> To: dev@cassandra.apache.org >>> Subject: Re: [DISCUSS] How to implement backward compatibility >>> (CASSANDRA-17048) >>> Though, the user is unable to test the new feature without enabling it. And >>> when it is enabled, the user is unable to revert it. >>> >>> - - -- --- - - >>> Jacek Lewandowski >>> >>> >>> On Tue, Oct 26, 2021 at 12:54 PM Bowen Song wrote: >>> >>>> Personally, I would prefer a transition period in which the new feature >>>> is not enabled by default. This not only makes version upgrading easier, >>>> it also allows the user to stay on the old behaviour if they experience >>>> any issue with the new feature (e.g.: bugs in the new feature, or edge >>>> use cases / 3rd party tools depending on the old behaviour) until the >>>> issue is resolved. >>>> >>>> On 26/10/2021 10:21, Jacek Lewandowski wrote: >>>>> Hi, >>>>> >>>>> In short, we are discussing UUID based sstable generation identifiers >>> in >>>> https://issues.apache.org/jira/browse/CASSANDRA-17048. >>>>> >>>>> The question which somehow hold us is support for downgrading. Long >>>> story short, when we generate new sstables with uuid based ids, they are >>>> not readable by older C* versions. >>>>> >>>>> 1. should we implement a downgrade tool? (it may be quite complex) >>>>> 2. should we let users enable the new uuid ids later when they are sure >>>> they will not downgrade in the future? >>>>> >>>>> Thanks, >>>>> Jacek >>>>> >>>>> >>>>> >>>>> - >>>>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org >>>>> For additional commands, e-mail: dev-h...@cassandra.apache.org >>>>> >>>> >>>> - >>>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org >>>> For additional commands, e-mail: dev-h...@cassandra.apache.org >>>> >>>> >>> >> > > - > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > For additional commands, e-mail: dev-h...@cassandra.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
Re: [DISCUSS] How to implement backward compatibility (CASSANDRA-17048)
Yes, those explanations sound very reasonable to me as well and I'll push the implementation soon. Thank you guys On 2021/10/26 18:21:44, Joshua McKenzie wrote: > +1 to Benedict's perspective here. Supporting both sstable ID paradigms > should be relatively trivial and low cost to maintain going forward. > > On Tue, Oct 26, 2021 at 7:54 AM bened...@apache.org > wrote: > > > I think it is probably acceptable to prevent downgrades once a new feature > > is enabled, as the exposure risk is limited to that one feature. The user > > can test the new version to ensure everything else works satisfactorily > > before committing to this one feature. > > > > A downgrade tool would also be possible to produce, but probably the > > additional utility is limited. > > > > I think this particular feature is probably easy enough to maintain as > > permanently optional, simply maintaining two system tables: one for the old > > generation format, one for the new. So long as the user doesn’t use the new > > format, it remains forever downgradeable. Though perhaps one day we may > > want to force users to migrate, I don’t think there’s any rush, and the > > important thing to avoid is providing users no version buffer to escape new > > bugs – if a major version later we force upgrade, then they have a whole > > range of major versions to downgrade to that still support this feature > > (but perhaps avoid some other new issue) > > > > > > > > From: Jacek Lewandowski > > Date: Tuesday, 26 October 2021 at 12:01 > > To: dev@cassandra.apache.org > > Subject: Re: [DISCUSS] How to implement backward compatibility > > (CASSANDRA-17048) > > Though, the user is unable to test the new feature without enabling it. And > > when it is enabled, the user is unable to revert it. > > > > - - -- --- - - > > Jacek Lewandowski > > > > > > On Tue, Oct 26, 2021 at 12:54 PM Bowen Song wrote: > > > > > Personally, I would prefer a transition period in which the new feature > > > is not enabled by default. This not only makes version upgrading easier, > > > it also allows the user to stay on the old behaviour if they experience > > > any issue with the new feature (e.g.: bugs in the new feature, or edge > > > use cases / 3rd party tools depending on the old behaviour) until the > > > issue is resolved. > > > > > > On 26/10/2021 10:21, Jacek Lewandowski wrote: > > > > Hi, > > > > > > > > In short, we are discussing UUID based sstable generation identifiers > > in > > > https://issues.apache.org/jira/browse/CASSANDRA-17048. > > > > > > > > The question which somehow hold us is support for downgrading. Long > > > story short, when we generate new sstables with uuid based ids, they are > > > not readable by older C* versions. > > > > > > > > 1. should we implement a downgrade tool? (it may be quite complex) > > > > 2. should we let users enable the new uuid ids later when they are sure > > > they will not downgrade in the future? > > > > > > > > Thanks, > > > > Jacek > > > > > > > > > > > > > > > > - > > > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > > > > For additional commands, e-mail: dev-h...@cassandra.apache.org > > > > > > > > > > - > > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > > > For additional commands, e-mail: dev-h...@cassandra.apache.org > > > > > > > > > - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
Re: [DISCUSS] How to implement backward compatibility (CASSANDRA-17048)
+1 to Benedict's perspective here. Supporting both sstable ID paradigms should be relatively trivial and low cost to maintain going forward. On Tue, Oct 26, 2021 at 7:54 AM bened...@apache.org wrote: > I think it is probably acceptable to prevent downgrades once a new feature > is enabled, as the exposure risk is limited to that one feature. The user > can test the new version to ensure everything else works satisfactorily > before committing to this one feature. > > A downgrade tool would also be possible to produce, but probably the > additional utility is limited. > > I think this particular feature is probably easy enough to maintain as > permanently optional, simply maintaining two system tables: one for the old > generation format, one for the new. So long as the user doesn’t use the new > format, it remains forever downgradeable. Though perhaps one day we may > want to force users to migrate, I don’t think there’s any rush, and the > important thing to avoid is providing users no version buffer to escape new > bugs – if a major version later we force upgrade, then they have a whole > range of major versions to downgrade to that still support this feature > (but perhaps avoid some other new issue) > > > > From: Jacek Lewandowski > Date: Tuesday, 26 October 2021 at 12:01 > To: dev@cassandra.apache.org > Subject: Re: [DISCUSS] How to implement backward compatibility > (CASSANDRA-17048) > Though, the user is unable to test the new feature without enabling it. And > when it is enabled, the user is unable to revert it. > > - - -- --- - - > Jacek Lewandowski > > > On Tue, Oct 26, 2021 at 12:54 PM Bowen Song wrote: > > > Personally, I would prefer a transition period in which the new feature > > is not enabled by default. This not only makes version upgrading easier, > > it also allows the user to stay on the old behaviour if they experience > > any issue with the new feature (e.g.: bugs in the new feature, or edge > > use cases / 3rd party tools depending on the old behaviour) until the > > issue is resolved. > > > > On 26/10/2021 10:21, Jacek Lewandowski wrote: > > > Hi, > > > > > > In short, we are discussing UUID based sstable generation identifiers > in > > https://issues.apache.org/jira/browse/CASSANDRA-17048. > > > > > > The question which somehow hold us is support for downgrading. Long > > story short, when we generate new sstables with uuid based ids, they are > > not readable by older C* versions. > > > > > > 1. should we implement a downgrade tool? (it may be quite complex) > > > 2. should we let users enable the new uuid ids later when they are sure > > they will not downgrade in the future? > > > > > > Thanks, > > > Jacek > > > > > > > > > > > > - > > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > > > For additional commands, e-mail: dev-h...@cassandra.apache.org > > > > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > > For additional commands, e-mail: dev-h...@cassandra.apache.org > > > > >
Re: [DISCUSS] How to implement backward compatibility (CASSANDRA-17048)
I think it is probably acceptable to prevent downgrades once a new feature is enabled, as the exposure risk is limited to that one feature. The user can test the new version to ensure everything else works satisfactorily before committing to this one feature. A downgrade tool would also be possible to produce, but probably the additional utility is limited. I think this particular feature is probably easy enough to maintain as permanently optional, simply maintaining two system tables: one for the old generation format, one for the new. So long as the user doesn’t use the new format, it remains forever downgradeable. Though perhaps one day we may want to force users to migrate, I don’t think there’s any rush, and the important thing to avoid is providing users no version buffer to escape new bugs – if a major version later we force upgrade, then they have a whole range of major versions to downgrade to that still support this feature (but perhaps avoid some other new issue) From: Jacek Lewandowski Date: Tuesday, 26 October 2021 at 12:01 To: dev@cassandra.apache.org Subject: Re: [DISCUSS] How to implement backward compatibility (CASSANDRA-17048) Though, the user is unable to test the new feature without enabling it. And when it is enabled, the user is unable to revert it. - - -- --- - - Jacek Lewandowski On Tue, Oct 26, 2021 at 12:54 PM Bowen Song wrote: > Personally, I would prefer a transition period in which the new feature > is not enabled by default. This not only makes version upgrading easier, > it also allows the user to stay on the old behaviour if they experience > any issue with the new feature (e.g.: bugs in the new feature, or edge > use cases / 3rd party tools depending on the old behaviour) until the > issue is resolved. > > On 26/10/2021 10:21, Jacek Lewandowski wrote: > > Hi, > > > > In short, we are discussing UUID based sstable generation identifiers in > https://issues.apache.org/jira/browse/CASSANDRA-17048. > > > > The question which somehow hold us is support for downgrading. Long > story short, when we generate new sstables with uuid based ids, they are > not readable by older C* versions. > > > > 1. should we implement a downgrade tool? (it may be quite complex) > > 2. should we let users enable the new uuid ids later when they are sure > they will not downgrade in the future? > > > > Thanks, > > Jacek > > > > > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > > For additional commands, e-mail: dev-h...@cassandra.apache.org > > > > - > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > For additional commands, e-mail: dev-h...@cassandra.apache.org > >
Re: [DISCUSS] How to implement backward compatibility (CASSANDRA-17048)
The user will be able to test the new feature in a testing environment and not push the changes to their production environment if they are not satisfied. On 26/10/2021 12:00, Jacek Lewandowski wrote: Though, the user is unable to test the new feature without enabling it. And when it is enabled, the user is unable to revert it. - - -- --- - - Jacek Lewandowski On Tue, Oct 26, 2021 at 12:54 PM Bowen Song wrote: Personally, I would prefer a transition period in which the new feature is not enabled by default. This not only makes version upgrading easier, it also allows the user to stay on the old behaviour if they experience any issue with the new feature (e.g.: bugs in the new feature, or edge use cases / 3rd party tools depending on the old behaviour) until the issue is resolved. On 26/10/2021 10:21, Jacek Lewandowski wrote: Hi, In short, we are discussing UUID based sstable generation identifiers in https://issues.apache.org/jira/browse/CASSANDRA-17048. The question which somehow hold us is support for downgrading. Long story short, when we generate new sstables with uuid based ids, they are not readable by older C* versions. 1. should we implement a downgrade tool? (it may be quite complex) 2. should we let users enable the new uuid ids later when they are sure they will not downgrade in the future? Thanks, Jacek - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
Re: [DISCUSS] How to implement backward compatibility (CASSANDRA-17048)
Though, the user is unable to test the new feature without enabling it. And when it is enabled, the user is unable to revert it. - - -- --- - - Jacek Lewandowski On Tue, Oct 26, 2021 at 12:54 PM Bowen Song wrote: > Personally, I would prefer a transition period in which the new feature > is not enabled by default. This not only makes version upgrading easier, > it also allows the user to stay on the old behaviour if they experience > any issue with the new feature (e.g.: bugs in the new feature, or edge > use cases / 3rd party tools depending on the old behaviour) until the > issue is resolved. > > On 26/10/2021 10:21, Jacek Lewandowski wrote: > > Hi, > > > > In short, we are discussing UUID based sstable generation identifiers in > https://issues.apache.org/jira/browse/CASSANDRA-17048. > > > > The question which somehow hold us is support for downgrading. Long > story short, when we generate new sstables with uuid based ids, they are > not readable by older C* versions. > > > > 1. should we implement a downgrade tool? (it may be quite complex) > > 2. should we let users enable the new uuid ids later when they are sure > they will not downgrade in the future? > > > > Thanks, > > Jacek > > > > > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > > For additional commands, e-mail: dev-h...@cassandra.apache.org > > > > - > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > For additional commands, e-mail: dev-h...@cassandra.apache.org > >
Re: [DISCUSS] How to implement backward compatibility (CASSANDRA-17048)
Personally, I would prefer a transition period in which the new feature is not enabled by default. This not only makes version upgrading easier, it also allows the user to stay on the old behaviour if they experience any issue with the new feature (e.g.: bugs in the new feature, or edge use cases / 3rd party tools depending on the old behaviour) until the issue is resolved. On 26/10/2021 10:21, Jacek Lewandowski wrote: Hi, In short, we are discussing UUID based sstable generation identifiers in https://issues.apache.org/jira/browse/CASSANDRA-17048. The question which somehow hold us is support for downgrading. Long story short, when we generate new sstables with uuid based ids, they are not readable by older C* versions. 1. should we implement a downgrade tool? (it may be quite complex) 2. should we let users enable the new uuid ids later when they are sure they will not downgrade in the future? Thanks, Jacek - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
[DISCUSS] How to implement backward compatibility (CASSANDRA-17048)
Hi, In short, we are discussing UUID based sstable generation identifiers in https://issues.apache.org/jira/browse/CASSANDRA-17048. The question which somehow hold us is support for downgrading. Long story short, when we generate new sstables with uuid based ids, they are not readable by older C* versions. 1. should we implement a downgrade tool? (it may be quite complex) 2. should we let users enable the new uuid ids later when they are sure they will not downgrade in the future? Thanks, Jacek - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
