IPv6 formatting in SCT different than Scylla, making it difficult to correlate logs

[kbr-scylla]

parallel-topology-schema-changes-mu-db-node-e330a762-9/messages.log:

2024-09-10T15:26:20.812+00:00 parallel-topology-schema-changes-mu-db-node-e330a762-9     !INFO | scylla[7134]:  [shard 0:main] init - seeds={2a05:d018:12e3:f000:455b:e46c:ed49:95c6}, listen_address=2a05:d01c:964:7d01:9e5:bac1:a3ae:f921, broadcast_address=2a05:d01c:964:7d01:9e5:bac1:a3ae:f921

note the broadcast_address=2a05:d01c:964:7d01:9e5:bac1:a3ae:f921

SCT log printing about that node:

< t:2024-09-10 16:05:46,444 f:cluster_aws.py  l:686  c:sdcm.cluster_aws     p:DEBUG > Node parallel-topology-schema-changes-mu-db-node-e330a762-9 [13.41.197.3 | 10.3.6.191 | 2a05:d01c:0964:7d01:09e5:bac1:a3ae:f921] (dc name: eu-west-2scylla_node_west, rack: 2b): ip_address is: 2a05:d01c:0964:7d01:09e5:bac1:a3ae:f921

ip_address is: 2a05:d01c:0964:7d01:09e5:bac1:a3ae:f921

find the difference...

[kbr-scylla]

encountered while investigating https://argus.scylladb.com/test/5cd4bfe3-231b-4f48-99bc-f21ebd1b5efe/runs?additionalRuns%5B%5D=e330a762-61b1-4318-a55c-0b072d4df26e

[fruch]

it's on purpose, since scylla or some of the tooling (i.e. nodetool) and cloud provider, we returning different formats
we decided to always use the full format, with leading zeros, to be able to compare correctly.

question is why scylla use the short format ?

is it specified anywhere in scylla code ? or by product of something else ?

[kbr-scylla]

looks like IPv6 printing was added in scylladb/seastar@97102fa by @elcallio
implementation

std::ostream& seastar::net::operator<<(std::ostream& os, const ipv6_address& a) {
    char buffer[64];
    return os << ::inet_ntop(AF_INET6, a.ip.data(), buffer, sizeof(buffer));
}

so it's using the standard inet_ntop function https://man7.org/linux/man-pages/man3/inet_ntop.3.html
defined in RFC 2553 https://datatracker.ietf.org/doc/html/rfc2553#section-6.6