tree d0df413875de89f5766f581c5195b0958159f3a4
parent 69a358670e180d51a9eefffc5752295ed06db233
author Bogdan Caprita <caprita@google.com> 1464805402 -0700
committer Bogdan Caprita <caprita@google.com> 1464814745 +0000

allocator: use the instance kubernetes name as the canonical instance key

The goal is to break the implicit relation between the kube name and the
mount name of the instance.  The mount name is generated for the
instance at creation time and then stored with the instance.  Deriving
one from the other after that point is fragile, since the format of
either could change in the future (or we could have zero or more mount
names per instance).

Most of the changes are mechanical and result in simplifications.  In
particular, the handlers are easier for users to work with than full
mount names.  There are two parts that become slighly more complex:

1. The dashboard handler still needs the mount name; instead of
extracting it from the deployment json (which would incur an extra
kubectl command), we pack it in the request url together with the
instance handle.  To prevent undue access, we sign the pair.

2. The allocator cmd-line tool "list" command now has two modes, showing
just the handles or full details about each instance.

While at it, also remove the transitional logic that filled in the mount
name and blessing names for instances that didn't have this persisted in
their deployment annotations.

Change-Id: I4380ad4d3376fa64961048838815fdc2f8e71a3a