peer status should display the state of the peer

[atinmu]

Add connected flag in peer object to indicate the health of the given peer

[prashanthpai]

I'll start working on this.

A GET on the peer will fetch static information about that peer from the store without contacting the peer.

[ppai@gd2-1 ~]$ curl -i -X GET http://127.0.0.1:24007/v1/peers/6b8ae6de-105d-4423-a3ee-214a72fd5b04
HTTP/1.1 200 OK
Content-Type: application/json; charset=UTF-8
Date: Thu, 17 Nov 2016 12:41:46 GMT
Content-Length: 145

{"id":"6b8ae6de-105d-4423-a3ee-214a72fd5b04","name":"192.168.56.26","addresses":["192.168.56.26"],"client":false,"memberID":7442247378072614556}

Adding status to the endpoint URL in future, should return health or online/offline status of the peer. This will contact the actual peer.

$ curl -i -X GET http://127.0.0.1:24007/v1/peers/6b8ae6de-105d-4423-a3ee-214a72fd5b04/status

[atinmu]

@prashanthpai when are we planning to pick this item?

[prashanthpai]

This is pretty much ready. I want some clarity on what things the response should really contain. glusterd1 only has a Connected field. In glusterd2, we can return result of etcdhealth endpoint. The response will ensure that gusterd2 process is up (because etcd is embedded) and that etcd cluster state is healthy. In glusterd2 peers do not have to main a persistent connection between each other. etcd does it for us. So what other information (if any) should be returned as peer status response ? @atinmu @kshlm

[atinmu]

@prashanthpai I guess that's about it until @kshlm has a different opinion

[aravindavk]

I think we should retain "Connected"(or "online") field. (Assuming API output from peer will be shown even if peer is down)

[prashanthpai]

Fixed in PR #200