I will revert it as I committed it, before the freeze.
I have to admit these points you have are all valid, this seems to be
harder than one might think. In this light, as it stands now, it is a
pretty much half-cooked solution doing potentially more harm than
good. The user had a request that "th
> The same backward compatibility mechanism needed for system-provided UUIDs
> will work for user-provided UUIDs.
By ignoring them, and assigning a different one? That seems confusing, and like
the feature will in effect be short lived.
It’s a very different problem to upgrade a set of IDs just
> One reason might be compatibility – this may (I hope _will_) migrate to a
simple integer of low cardinality in future, which would be a breaking
change.
I look forward to this change, but won't we need to implement some backward
compatibility handling for legacy UUIDs anyway? The same backward
c
One reason might be compatibility – this may (I hope _will_) migrate to a
simple integer of low cardinality in future, which would be a breaking change.
This identifier will likely be used by Accord for correctness, too, and doing
something wrong with it could have severe consequences, so at the
> starting a new node with the same id as an existing live node will cause
a collision
Is this not fixed if we add a simple collision check for existing host id?
We can file a bug request and add this check which should be fairly
straightforward.
> it would be pretty untenable to base any new/im
Like I mentioned, the possibility of easily introducing divergent views of the
ring between live nodes is pretty dangerous, e.g. starting a new node with the
same id as an existing live node will cause a collision. The existing node will
not add the new node to the ring (although it will remain
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 t
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
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
