I wanted to close the loop on this discussion and here's how I would summarize the discussion:
1. Prioritize user intuition: Both Jaydeep and Josh agreed that user intuition should take priority over internal system consistency, since the storage port "does not reflect how end-user traffic works in production" 2. Hybrid format: Mick proposed a compromise format like "192.168.1.100:9042[7000]" that could show both ports 3. Broader infrastructure concern: Paulo raised the broader issue that IP:ports aren't true node identifiers and suggested using actual host IDs. We can defer this effort for a different JIRA 4. User experience focus: The consensus leans toward making audit logs more intuitive for users who are primarily concerned with auditing client connections rather than internal Cassandra operations I will move forward and work on CASSANDRA-20826. There's still the open question whether this change will land in trunk only or if we want to backport it to all active branches. Best, - Francisco On 2025/08/18 18:19:55 Francisco Guerrero wrote: > > 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]" ? >
