[WIP] Show some IPAM stats with "weave status ipam"

[inercia]

Fixes #1639

[bboreham]

weave status gives some IPAM information (same as prior to this PR):

      Service: ipam
    Consensus: achieved
        Range: 10.32.0.0-10.47.255.255
DefaultSubnet: 10.32.0.0/12

and this PR then repeats some of that information:

$ weave status ipam
      Universe: 10.32.0.0-10.47.255.255 (1048576 IPs)
 DefaultSubnet: 10.32.0.0/12
    Containers:
                da001e7156cddd081b1e888ca150d228ec90301d83b65d47ead4a823b891f07b: [10.32.0.1]
    Ownerships:
             (local):  1048576 IPs (100.0% of universe, in   1 ranges) - used:        1 IPs 

This is different to weave status dns which doesn't repeat anything from weave status.

And the name Universe is Range in weave status

[bboreham]

Note that two peers can have the same nickname; this happens when you weave reset a peer and then launch it again. So the output needs to distinguish those two instances.

[rade]

Please bear in mind the issue (#1639) that this is meant to address. What is the most useful information we can show ?

[bboreham]

Currently I have it like this:

         Range: 10.32.0.0-10.47.255.255 (1048576 IPs)
 DefaultSubnet: 10.32.0.0/12
    Containers:
                da001e7156cd: [10.32.0.1]
    Ownerships:
fe:e2:23:09:da:02(local):   262146 IPs (25.0% of total) - used: 2 
ce:98:83:03:49:44(host1):   262143 IPs (25.0% of total) - used: 1 
22:d8:76:19:b1:59(host1):   524287 IPs (50.0% of total) - used: 1 - unreachable!

So it's possible to see we have two instances of host1, one of which is "dead".

[rade]

ok. need to think about what to put in the weave status summary, e.g. as per #1639 (comment).

I am not keen on showing lists mixed with other stuff. Perhaps we should just show what you currently have under "Ownerships"?

(I don't think we need "Containers", plus I think it's confusing, since it's local-only)

[bboreham]

OK, now we have this warning in the main weave status:

       Service: ipam
     Consensus: achieved - all IPs owned by unreachable peers!
         Range: 10.32.0.0-10.47.255.255
 DefaultSubnet: 10.32.0.0/12

And weave status ipam is like this:

ce:98:83:03:49:44(host1):   524289 IPs (50.0% of total) - unreachable!
22:d8:76:19:b1:59(host1):   524287 IPs (50.0% of total) - unreachable!

[rade]

hmm. We may want to revise our terminology here. Sounds a lot like "success - it's completely broken!"

[bboreham]

Latest version:

       Service: ipam
        Halted: all IPs owned by unreachable peers
         Range: 10.32.0.0-10.47.255.255
 DefaultSubnet: 10.32.0.0/12

Maybe "Consensus: halted - ..." would be better for people parsing the output? It's not really the consensus that is halted.

[rade]

perhaps go for the more generic "Status", with values of "idle", "awaiting consensus", "all IPs owned by unreachable peers - waiting for them to come online or be removed with 'rmpeer'", "ready". or something like that.

[bboreham]

Note I have changed the implementation recently:

• All data exported from ipam/status.go is now strings and numbers, in keeping with the original design.
• IPAM.Entries now has the nickname and known-peer status on each entry, so people parsing weave report can do the same computation weave status does. This is more verbose.
• I removed IPAM.Owned since it is not required for this issue. It might have been useful for debugging.

[bboreham]

The code currently prints the nickname of the local node as (local), which is quite nice but inconsistent with weave status peers which just prints its nickname (e.g. derived from the host).

[rade]

ditch the local.

[bboreham]

OK, now we have:

    Status: all IPs owned by unreachable peers - use 'rmpeer' if they are dead
    Status: ready
    Status: awaiting consensus (quorum: X, known: Y)
    Status: idle

("idle" is the old "deferred")

and "local" is gone.

[rade]

should we have a state indication about pending requests? Which can happen in all except the idle state, but I think is mainly interesting in the 'ready' state. Perhaps we could split 'ready' into 'ready' and 'waiting for space grant from other peers' (or something like that).

[bboreham]

There can be pending allocations (any address in a subnet) and pending claims (one specific address). The former generally indicates someone is blocked; the latter may or may not (it's ok to continue using an address that is "owned" by a peer that is actually dead).

So I will print a message for pending allocations only.

[bboreham]

OK, now we have:

    Status: ready - waiting for space grant from peers

It isn't possible to see exactly who we are waiting for, even using weave report, as the PendingAllocates don't give the subnet. I'll add that.

[rade]

ready - waiting for space grant from peers

I would ditch the "ready" bit.

[rade]

also "space" is an odd term. "waiting for IP address grant from peers"? or "IP address range". or "IP range". or "IP".

[bboreham]

Now Status: waiting for IP range grant from peers.

If no further comments I will squash the commits.

[rade]

please show an example of the output of the ipam section of weave status, and the output of weave status ipam.

[awh]

Needs buttery base

[bboreham]

Rebased

[awh]

@bboreham I suspect you missed my other comments about the weave status ipam output...

[bboreham]

the padding of the name/nickname field has not worked correctly - the IP counts should be aligned vertically

the alignment is consistent with previous code; it doesn't work if your hostname is over 9 chars long

[bboreham]

Updated sample output:

$ weave status ipam
4a:95:cd:2b:cb:35(bbvlx1)               524288 IPs (50.0% of total) 
66:9a:14:47:6b:2d(host1)                524288 IPs (50.0% of total) 

and updated weave status peers to match alignment up to 14-char hostname:

$ weave status peers
4a:95:cd:2b:cb:35(bbvlx1)
   -> 192.168.48.11:6783    66:9a:14:47:6b:2d(host1)              established
66:9a:14:47:6b:2d(host1)
   <- 192.168.48.1:40739    4a:95:cd:2b:cb:35(bbvlx1)             established