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 <dcapw...@apple.com.invalid> 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 <jmcken...@apache.org> 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 <lewandowski.ja...@gmail.com> > >>> Date: Tuesday, 26 October 2021 at 12:01 > >>> To: dev@cassandra.apache.org <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 <bo...@bso.ng.invalid> > 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 > >
