CASSANDRA-14582 added support for users to supply an arbitrary value for HOST_ID when booting a new node. IMO it's a pretty bad and potentially dangerous idea for the unique identifier to be settable in this way. Hint delivery is already routed by host id and there have been several JIRAs which have called for more fundamental reworking of cluster metadata using permanent opaque identifiers rather than IPs to address members (CASSANDRA-11559, CASSANDRA-15823, etc). Using host id for anything like that in future would be made much more difficult with this capability.
Aside from the longer term implications, it seems that the feature as currently implemented has some issues. There doesn't appear to be any validation that a supplied host id isn't already in use by a live node, so it's trivial to trigger a collision which can lead to divergent ring views between nodes and ultimately in data loss. Although this landed in trunk almost 11 months ago it hasn't been included in a release yet, so I propose we revert it before cutting 4.1 (although, as the revert isn't a feature, I guess technically we could do that during the freeze). I'm not completely convinced about encoding metadata into host ids, but even if that is something we want to do, I don't think it's wise to completely remove control over the identifiers from Cassandra itself. Thanks, Sam > On 25 Apr 2022, at 16:17, Ekaterina Dimitrova <e.dimitr...@gmail.com> wrote: > > Hi everyone, > > Kind reminder that 1st May is around the corner. What does this mean? Our > code freeze starts on 1st May and my understanding is that only bug fixing > can go into the 4.1 branch. > If anyone has anything to raise, now is a good time. On my end I saw a few > things for this week that we should probably put to completion: > - CASSANDRA-17571 <https://issues.apache.org/jira/browse/CASSANDRA-17571> - I > have to close this one, it is in progress; new types in Config is good to be > in before the freeze I guess, even if It is not yaml change > - CASSANDRA-17557 <https://issues.apache.org/jira/browse/CASSANDRA-17557> - > we need to take care of the parameters so we don't have to deprecate and > support anything not actually needed; I think it is probably more or less done > - CASSANDRA-17379 <https://issues.apache.org/jira/browse/CASSANDRA-17379> - > adds a new flag around config; I think it is more or less done, depends on > final CI and second reviewer maybe needed? > - JMX intercept Cassandra exceptions, I think David mentioned a rebase was > needed > - CASSANDRA-17212 - The config property minimum_keyspace_rf and their > nodetool getter and setter commands are new to 4.1. They are suitable to be > ported to guardrails, and if we do this port in 4.1 we won't need to > deprecate that property and nodetool commands in the next release, just one > release after their introduction. > > I guess the failing tests we see could be fixed after the freeze but no API > changes. > > Thanks everyone for all the hard work. Please don’t hesitate to raise the > flag with questions, concerns or any help needed. > > Best regards, > Ekaterina
