[RFC] spec: add image tags

[sgotti]

I tried to implement, also to see possible problems, the @mpasternacki proposal of image tags #575 (comment)

I'm not sure if this is going to create too much complexity. For sure it'll add some complexity on managing them inside rkt to fit its needs to cache data locally and to obtain the same images that will be obtained doing discovery.
But it'll also fix some of the problems reported in #575 and other issues.
Probably it'll break some current behaviours but I can't find a way to make it completely backward compatible (or perhaps these behaviours will be broken just because they aren't correct).

Doing this I met (again) the need to finally define the image string format (#479), but I left it for the future.

Probably the wording in the spec can be vastly improved. I just tried to trigger an initial discussion.

This patch introduces the concept of image tags.

Since many ACEs (like rkt) wants to implement local caching I tried to
define Image Tags considering this as a primary requirement.

While an image is static since its labels are written in its manifest and
changing them will change the image id, image tags are dynamic.

In short words it adds another file that contains a map to convert a tag
to another tag (alias) and/or expand a tag to a set of labels.
It practically adds a layer above current image discovery used to obtain
the final set of labels to use to calcultae ac-discovery URLs.

Image Tags are defined to be per image name. This is needed to satisfy
the need to locally cache them (since they should be cached and retrieved
using a key and this key is the image name).

This will be useful to fix different issues and enhancements.

This patch:

• Introduces Image Tags format.
• Details the discovery process (since there's now an optional
  additional step)
• Adds a "tag" inside image dependencies in image manifest
• Changes the app string format parsing function. It now defines the
  value after the ":" as a Tag instead of the version label.
• Adds code for doing tag resolution and labels merging (that can be used
  by an ACE). As a fallback, if no image tags data is provided, the
  version label will be set from the tag value.
• The image tags fetching and verification logic is left to the ACE
  (like done for an ACI).

Docker compatibility

Actually docker2aci converts a docker image (squashing it) to an ACI and
sets the version label to the image tag. This is a fast but not
consistent way to use docker tags since they can be dynamically changed.

With this proposal an idea will be to convert docker tags to an
Image Tags file (using the docker APIs). Docker tags are per
repository and a repository is mapped to an ACI image name. So this should match the proposal that defines imagetags per image.

Docker images don't have a version label but can have a label
representing the docker image ID. So an image tag can point to that
"dockerimageid" label.

rkt related work

For rkt, the changes to implement to satisfy image tags should be:

• Image Tags fetching and validation
• Labels Merging (calling imageTags.MergeTag providing the starting
• labels and tag value)
• Caching of Tags Data per app name
• Use of imageTags.MergeTag before calling GetACI.
• Removal of "latest" column from the store since it was an hack around current spec default "latest" version.
• rkt image list shouldn't show app:$version but app,version=$version. Or better, since this can be confusing, just split them and use a column for app name and a column for all the ACI labels.

Some open points:

• Since there're an additional layer and an additional file there's the need to:
  • inspect Image Tags data (like the current rkt image list there
    should be something like rkt imagetags list)
  • fetch/update them (they are automatically fetched using rkt --no-store fetch imagename, but this will also fetch an image). To
    just fetch/update ImageTags something like rkt imagetags --no-store fetch {IMAGENAME|file|URL}
    should be added. Providing and image name will use discovery, while the other will
    just fetch it from the provided file/URL.
• Since rkt also accept fetching an image from a file or URL, doing this
  won't carry Image Tags information. So a successive attemp to run an
  image by its image string can use a different image than the one that
  will be run using an image discovery returning Image Tags data (due to
  the fallback of setting the version label value to tag if no image tag
  data is available). So a command like the above rkt imagetags fetch is
  needed also for this reason.