spec: Refactor NodeID a la VolumeHandle

[akutz]

This issue is a proposal to refactor the NodeID so that it is inline with a VolumeHandle. For example:

Old

message NodeID {
  // Information about a node in the form of key-value pairs. This
  // information is opaque to the CO. Given this information will be
  // passed around by the CO, it is RECOMMENDED that each Plugin keeps
  // this information as small as possible. This field is REQUIRED.
  map<string, string> values = 1;
}

New

message NodeID {
  string id = 1;
  map<string, string> metadata = 2;
}

This would make it much easier to refer to a Node by some meaningful piece of information, such as an IP address or hostname, without embedding that information in an opaque map.

I would not have suggested such a change as I believe the opaqueness of the data maps is a virtue, but with the change to a volume's ID, this seems like a consistent shift towards that direction.

[jdef]

I like the idea of consistency. Along such lines, id would not be sensitive but metadata could contain sensitive information?

Not sure how crazy I am about stuffing IPs into metadata if there's a possibility that they're going to change. NodeID is expected to NOT CHANGE once it's generated by the plugin.

[akutz]

Hi @jdef,

It doesn't need to be IP addresses. It could be, for example, an EC2 Instance Identity document. The NodeID's ID field could be some unique piece of information that could be easily hashed or searched in a map and the metadata could be the rest of the document marshalled as JSON and then unmarshalled into a map.

[jieyu]

I am +1 on this change. @saad-ali is working on adding topology information to NodeID. You may want to sync with him on that.

[saad-ali]

I think we should simplify NodeId and VolumeHandle to a simple string. See #116. Topology can be addressed separately.

[saad-ali]

So far a simple string has worked fine for existing CO and driver implementations. Therefore before we go to 1.0 we are closing this out.