I agree that a new configuration layout should be introduced once only, not
incrementally.
However, I disagree that we should immediately deprecate the old config file
and refuse to parse it. We can maintain compatibility indefinitely at low cost,
so we should do so.
Users of the old format, w
+1 to a non-incremental approach as well.
On 23/2/22 1:27, Caleb Rackliffe wrote:
@Patrick I’m absolutely intending for this to be a 5.0 concern. The only reason
why it would have any bearing on 4.x is the case where we’re adding new config
that could fit into the v2 structure now and not requ
@Patrick I’m absolutely intending for this to be a 5.0 concern. The only reason
why it would have any bearing on 4.x is the case where we’re adding new config
that could fit into the v2 structure now and not require any later changes.
> On Feb 22, 2022, at 3:22 PM, Bernardo Sanchez
> wrote:
>
I think we can easily support a hybrid world where we can support legacy
configuration safely while allowing new clusters from leveraging modern
configuration. And eventually "switch" to only support the new
configuration layout.
> If we make "a big cut" and old way of doing things would not be po
DTests are one side but to be clear, the main reason for backward
compatibility to be introduced in 15234 were not the tests but the users.
That was a very clear requirement and in my mind this work also intends to
have some backward compatibility? No?
But DTests and even in-jvm are quite a valid c
I want to add that to, however, on the other hand, we also do have
dtests in Python and they need to run with old configs too. That is
what Ekaterina was doing - supporting old configuration while
introducing new one. If we make "a big cut" and old way of doing
things would not be possible, how are
+1 to what Patrick says.
On Tue, 22 Feb 2022 at 21:40, Patrick McFadin wrote:
>
> I'm going to put up a red flag of making config file changes of this scale on
> a dot release. This should really be a 5.0 consideration.
>
> With that, I would propose a #5. 5.0 nodes will only read the new config
I'm going to put up a red flag of making config file changes of this scale
on a dot release. This should really be a 5.0 consideration.
With that, I would propose a #5. 5.0 nodes will only read the new config
files and reject old config files. If any of you went through the config
file changes fro
Glad to be agree on #4. That feature could be add anytime.
If a version element is added to the YAML, then it is not necessary to change
the filename, thus we could end up with #3. The value of the version element
could default to 1 in the first phase, which does not need any change for
legacy
I don’t really care much about what the actual structure ends up being. My
main suggestion would be that we do not do anything “incremental” here. I
think that would just cause more confusion to have some properties using a new
format and some using the current format. There should be some co
My initial preference would be something like combining #1 and #4. We could
add something like a simple "version: <1|2>" element to the YAML that would
eliminate any possible confusion about back-compat *within* a given file.
Thanks for enumerating these!
On Tue, Feb 22, 2022 at 10:42 AM Tibor Ré
Hi,
I like the idea of having cassandra.yaml better structured, as an operator, my
primer concern is the transition. How would we change the config structure from
legacy to the new one during a rolling upgrade? My thoughts on this:
1. Legacy and new configuration is stored in different files. C
Took the liberty to update the confluence wiki to reflect the "create branch
off last released tag with only delta required" for hotfixes.
https://cwiki.apache.org/confluence/display/CASSANDRA/Patching%2C+versioning%2C+and+LTS+releases
If anyone disagrees please let me know.
On Tue, Feb 15, 202
The vote passes, with 4 binding +1 votes, 4 non-binding +1 votes, and zero
binding vetos.
> On Feb 21, 2022, at 11:11 AM, Caleb Rackliffe
> wrote:
>
>
> Given this spanned the weekend, I'll leave the vote open for today...
>
>> On Fri, Feb 18, 2022 at 10:27 PM Dinesh Joshi wrote:
>> +1
>>
14 matches
Mail list logo
