To clarify a bit more, I don't think that ticket adds ability to encode metadata into host IDs, Cassandra still interprets the host uuid as a permanent opaque identifier. So I don't get why this can be a potential problem if we add the necessary host_id collision check.
Users may want to control their node UUIDs for inventory purposes, so this seems like a valid use case for this feature. Em qua., 27 de abr. de 2022 às 14:20, Paulo Motta <pauloricard...@gmail.com> escreveu: > Fully agree we should add a collision check but I don't understand why > this optional feature is bad/dangerous after we add this ability? Can you > provide an example of a potential issue? > > I don't expect this property to be used by most users, except power users > which normally know what they're doing. We have tons of potentially > dangerous knobs and I don't get why this particular one is any different. > > Em qua., 27 de abr. de 2022 às 14:05, Sam Tunnicliffe <s...@beobal.com> > escreveu: > >> 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 >> >> >>
