fix memberList inconsistent output

[tangcong]

We also encountered issue #9975 #9535, this pr supports to print memberlist in hex format json and does not break backward compatibility.
It seems to be a simple problem, but it is not so elegant to solve. I prefer to implement Marshal MemberListResponse manually, rather than redefining a redundant structure to implement the member id Marshal method. @jingyih @gyuho

[tangcong]

etcdctl member list

8211f1d0f64f3269, started, infra1, http://127.0.0.1:12380, http://127.0.0.1:2379, false
91bc3c398fb3c146, started, infra2, http://127.0.0.1:22380, http://127.0.0.1:22379, false
fd422379fda50e48, started, infra3, http://127.0.0.1:32380, http://127.0.0.1:32379, false

etcdctl member list -w=json --hex | python -m json.tool

{
    "header": {
        "cluster_id": "ef37ad9dc622a7c4",
        "member_id": "8211f1d0f64f3269",
        "raft_term": 7
    },
    "members": [
        {
            "ID": "8211f1d0f64f3269",
            "clientURLS": [
                "http://127.0.0.1:2379"
            ],
            "name": "infra1",
            "peerURLs": [
                "http://127.0.0.1:12380"
            ]
        },
        {
            "ID": "91bc3c398fb3c146",
            "clientURLS": [
                "http://127.0.0.1:22379"
            ],
            "name": "infra2",
            "peerURLs": [
                "http://127.0.0.1:22380"
            ]
        },
        {
            "ID": "fd422379fda50e48",
            "clientURLS": [
                "http://127.0.0.1:32379"
            ],
            "name": "infra3",
            "peerURLs": [
                "http://127.0.0.1:32380"
            ]
        }
    ]
}

[xiang90]

@tangcong

can you just redefine ClusterID and other IDs as a JSONHexID type? And define a json marshaller on it? So we do not need to reconstruct a full json encoder for the entire memberlistrepons.

[xiang90]

something like https://gist.github.com/nikravi/e4812ed46ad77d8d2aee60faddd205df#file-hexbytearray-go-L17-L37 for the ID type.

[tangcong]

thanks.i tried this implementation but memberlist response is a pb srtuct and we have to redefine a repeat struct, it looks not good. do you prefer this implementation?

[xiang90]

@tangcong The idea looks fine. But I suggest a better implementation.

[tangcong]

if we redefine ClusterID and other IDs as a JSONHexID type, we have to redefine following pb generated structs. @xiang90

type MemberListResponse struct {
	Header *ResponseHeader `protobuf:"bytes,1,opt,name=header" json:"header,omitempty"`
	// members is a list of all members associated with the cluster.
	Members []*Member `protobuf:"bytes,2,rep,name=members" json:"members,omitempty"`
}

type ResponseHeader struct {
	// cluster_id is the ID of the cluster which sent the response.
	ClusterId uint64 `protobuf:"varint,1,opt,name=cluster_id,json=clusterId,proto3" json:"cluster_id,omitempty"`
	// member_id is the ID of the member which sent the response.
	MemberId uint64 `protobuf:"varint,2,opt,name=member_id,json=memberId,proto3" json:"member_id,omitempty"`
	// revision is the key-value store revision when the request was applied.
	// For watch progress responses, the header.revision indicates progress. All future events
	// recieved in this stream are guaranteed to have a higher revision number than the
	// header.revision number.
	Revision int64 `protobuf:"varint,3,opt,name=revision,proto3" json:"revision,omitempty"`
	// raft_term is the raft term when the request was applied.
	RaftTerm uint64 `protobuf:"varint,4,opt,name=raft_term,json=raftTerm,proto3" json:"raft_term,omitempty"`
}

type Member struct {
	// ID is the member ID for this member.
	ID uint64 `protobuf:"varint,1,opt,name=ID,proto3" json:"ID,omitempty"`
	// name is the human-readable name of the member. If the member is not started, the name will be an empty string.
	Name string `protobuf:"bytes,2,opt,name=name,proto3" json:"name,omitempty"`
	// peerURLs is the list of URLs the member exposes to the cluster for communication.
	PeerURLs []string `protobuf:"bytes,3,rep,name=peerURLs" json:"peerURLs,omitempty"`
	// clientURLs is the list of URLs the member exposes to clients for communication. If the member is not started, clientURLs will be empty.
	ClientURLs []string `protobuf:"bytes,4,rep,name=clientURLs" json:"clientURLs,omitempty"`
	// isLearner indicates if the member is raft learner.
	IsLearner bool `protobuf:"varint,5,opt,name=isLearner,proto3" json:"isLearner,omitempty"`
}

[xiang90]

@tangcong

yes. but i feel redefining the type is better than writing our own encoder, which is error-prone. alternatively, we can write tests to ensure the hex encoder is always correct.

[tangcong]

yes,i added a test case to verify its correctness. @xiang90

[xiang90]

lgtm