+1 on introducing compile time checks to ensure backward compatibility. Confusion due to usage of deprecated settings is understandable. However, settings marked deprecated should produce a warning in logs so that the operators become aware of their usage in the YAML and can migrate to the newer settings.
Also breakages do happen once in a while. As long as we fix them quickly and/or revert the code in the meanwhile it's fine. > On Feb 12, 2022, at 3:56 AM, Ekaterina Dimitrova <e.dimitr...@gmail.com> > wrote: > > 15234 was a discussion about changing names and making parameters work with > the old ones. Still working parameters, backward compatibility and not > placeholders. > > Benedict, I can understand that when I said removal in this ticket you > thought I will deprecate in Config but unfortunately it is not what I meant. > I should have asked you also for review. I take the responsibility of doing > a mistake here by removing in minor release thinking this is a bug that leads > to dangerous confusion you can still use them. Indeed CHANGES.txt entry was > created but not NEWS.txt and it requires a person to check which exact > parameters were removed to take an action. I pushed a patch already to fix > this. Docs are also on the way now when ADOC migration is over. > > One of the yaml parameters was actually also already removed with the rewrite > of the messaging system in 4.0. I added back that one to Config too > yesterday, to be on the safe side. > > “ I wonder if we should introduce a compile time check that validates config > compatibility with prior versions, to avoid this in future” > > I think David is working on some tests to catch removed config in trunk, I > will follow up on Monday with him. > > On Sat, 12 Feb 2022 at 5:49, bened...@apache.org <mailto:bened...@apache.org> > <bened...@apache.org <mailto:bened...@apache.org>> wrote: > As discussed on 15234, there is never a rush to remove Config parameters, and > it should only be done when there’s some clear value. Since the overhead of > having an unused parameter is ~zero, in my opinion this occurs only when we > really need the operator to consider the semantic impact of its deprecation. > > > > We should never break minor upgrades, but we shouldn’t break any upgrade > unnecessarily. > > > > I wonder if we should introduce a compile time check that validates config > compatibility with prior versions, to avoid this in future. > > > > From: Dinesh Joshi <djo...@apache.org <mailto:djo...@apache.org>> > Date: Saturday, 12 February 2022 at 00:09 > To: dev@cassandra.apache.org <mailto:dev@cassandra.apache.org> > <dev@cassandra.apache.org <mailto:dev@cassandra.apache.org>> > Subject: Re: [RELEASE] Apache Cassandra 4.0.2 released > > We should also have deprecation guidance in Config.java. This will help when > anybody is making changes in the future. > > > > > On Feb 11, 2022, at 3:07 PM, Ekaterina Dimitrova <e.dimitr...@gmail.com > <mailto:e.dimitr...@gmail.com>> wrote: > > > > Note taken, I had to document only in 4.0.x that those are placeholder. I > just opened ticket to fix that - CASSANDRA-17377. I am going to submit a > patch soon > > > > On Fri, 11 Feb 2022 at 17:44, Jeff Jirsa <jji...@gmail.com > <mailto:jji...@gmail.com>> wrote: > > We don't HAVE TO remove the Config.java entry - we can mark it as deprecated > and ignored and remove it in a future version (and you could update > Config.java to log a message about having a deprecated config option). It's a > much better operator experience: log for a major version, then remove in the > next. > > > > On Fri, Feb 11, 2022 at 2:41 PM Ekaterina Dimitrova <e.dimitr...@gmail.com > <mailto:e.dimitr...@gmail.com>> wrote: > > This had to be removed in 4.0 but it wasn’t. The patch mentioned did it to > fix a bug that gives impression those work. Confirmed with Benedict on the > ticket. > > > > I agree I absolutely had to document it better, a ticket for documentation > was opened but it slipped from my mind with this emergency release this week. > It is unfortunate it is still in our backlog after the ADOC migration. > > > > Note taken. I truly apologize and I am going to prioritize CASSANDRA-17135. > Let me know if there is anything else I can/should do at this point. > > > > On Fri, 11 Feb 2022 at 17:26, Erick Ramirez <erick.rami...@datastax.com > <mailto:erick.rami...@datastax.com>> wrote: > > (moved dev@ to BCC) > > > > It looks like the otc_coalescing_strategy config key is no longer supported > in cassandra.yaml in 4.0.2, despite this not being mentioned anywhere in > CHANGES.txt or NEWS.txt. > > > > James, you're right -- it was removed by CASSANDRA-17132 > <https://issues.apache.org/jira/browse/CASSANDRA-17132> in 4.0.2 and 4.1. > > > > I agree that the CHANGES.txt entry should be clearer and we'll improve it > plus add detailed info in NEWS.txt. I'll get this done soon in > CASSANDRA-17135 <https://issues.apache.org/jira/browse/CASSANDRA-17135>. > Thanks for the feedback. Cheers! > > >
