[
https://issues.apache.org/jira/browse/CASSANDRA-5302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michał Michalski updated CASSANDRA-5302:
----------------------------------------
Description:
My pedantic nature can't stand having unaligned columns in nodetool outputs,
which happens when IP addresses are IPv6 ones:
{noformat}michal@aperture$ nodetool -h myhost status
Datacenter: DC1
==================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
-- Address Load Owns (effective) Host ID
Token Rack
UN 2001:3c27:21:166:0:1:2:7 331.65 GB 100,0%
d557fb83-72f2-4e92-9f26-de6c788aada5 85070591730234615865843651857942052864
rack2
UN 2001:3c27:21:166:0:1:1:7 328.8 GB 100,0%
0461a4bf-97a6-447d-9d06-3b42ad1f702c 0
rack1
{noformat}
I'm attaching a patch that fixes this problem for nodetool status / ring
commands. It does it by picking first item in nodes list (for nodetool ring
it's first node in general, for nodetool status it's first node in each DC) and
uses its length as a field length for output.
It bases on assumptions that it's imppossible to have 0 nodes in cluster/DC and
the lenghts of addresses are "similar". Alternative I'm considering is finding
the longest address - it will be 100% accurate.
was:
My pedantic nature can't stand having unaligned columns in nodetool outputs,
which happens when IP addresses are IPv6 ones:
{noformat}michal@aperture$ nodetool -h myhost status
Datacenter: DC1
==================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
-- Address Load Owns (effective) Host ID
Token Rack
UN 2001:3c27:21:166:0:1:2:7 331.65 GB 100,0%
d557fb83-72f2-4e92-9f26-de6c788aada5 85070591730234615865843651857942052864
rack2
UN 2001:3c27:21:166:0:1:1:7 328.8 GB 100,0%
0461a4bf-97a6-447d-9d06-3b42ad1f702c 0
rack1
{noformat}
I'm attaching a patch that fixes this problem for nodetool status / ring
commands. It does it by picking first item in nodes list (for nodetool ring
it's first node in general, for nodetool status it's first node in each DC) and
uses its length as a field length for output.
It bases on assumptions that it's imppossible to have 0 nodes in cluster/DC and
the lenghts of addresses are equal. Let me know if there's the case when it's
not valid.
> Fix nodetool ring and status output format for IPv6 addresses
> -------------------------------------------------------------
>
> Key: CASSANDRA-5302
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5302
> Project: Cassandra
> Issue Type: Improvement
> Components: Tools
> Reporter: Michał Michalski
> Assignee: Michał Michalski
> Priority: Trivial
> Attachments: 5302.patch
>
>
> My pedantic nature can't stand having unaligned columns in nodetool outputs,
> which happens when IP addresses are IPv6 ones:
> {noformat}michal@aperture$ nodetool -h myhost status
> Datacenter: DC1
> ==================
> Status=Up/Down
> |/ State=Normal/Leaving/Joining/Moving
> -- Address Load Owns (effective) Host ID
> Token Rack
> UN 2001:3c27:21:166:0:1:2:7 331.65 GB 100,0%
> d557fb83-72f2-4e92-9f26-de6c788aada5 85070591730234615865843651857942052864
> rack2
> UN 2001:3c27:21:166:0:1:1:7 328.8 GB 100,0%
> 0461a4bf-97a6-447d-9d06-3b42ad1f702c 0
> rack1
> {noformat}
> I'm attaching a patch that fixes this problem for nodetool status / ring
> commands. It does it by picking first item in nodes list (for nodetool ring
> it's first node in general, for nodetool status it's first node in each DC)
> and uses its length as a field length for output.
> It bases on assumptions that it's imppossible to have 0 nodes in cluster/DC
> and the lenghts of addresses are "similar". Alternative I'm considering is
> finding the longest address - it will be 100% accurate.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
