> Is this host field used for anything other than identification ? I believe that will be the case for most use cases
> If it's purely an identifier field without need to the format, could it be in > the form "192.168.1.100:9042[7000]" ? I think this could still lead to confusion for someone without knowledge of Cassandra internals and that is looking at it from an auditing point of view only. On 2025/08/18 12:34:32 Mick wrote: > > > > > > I'd like to bring up for discussion the host field in audit logs, which > > currently shows > > the storage port (e.g., 192.168.1.100:7000) instead of the native port > > users expect to see. > > > > Background: > > - Original implementation[1] used storage port for consistency with other > > subsystems > > - CASSANDRA-7544[2] enabled multiple instances per IP, making storage > > port the > > standard differentiator > > - This creates confusion for users reviewing client audit logs who expect > > to see the > > native port (i.e 9042) > > > > Arguments: > > - Keep storage port: Consistent with gossip/repair/logs, maintains > > existing behavior > > - Switch to native port: More intuitive for audit log analysis, matches > > user expectations > > > > Considerations: > > 1. Should audit logs prioritize consistency with internal systems or user > > intuition? > > 2. Would this change break existing tooling? > > 3. Should the change only land in trunk, or backport to all branches up > > to 4.0? > > > Out of curiosity… > Is this host field used for anything other than identification ? > If it's purely an identifier field without need to the format, could it be in > the form "192.168.1.100:9042[7000]" ?
