Our kubernetes yaml specifications use a pull-policy of always and tag of :latest which will cause unexpected troubles.
If I build a cluster today, and get version 1.0 as latest, and the source pushes a new docker image where latest becomes 2.0 and a node in the cluster restarts, and therefore re-pulls (with the pull-policy = always), the node that was running a 1.0 service and which may be tied to a 1.0 API will now be requesting 1.2 and fail.

The pull-policy and image tag naming schemes should be repeatable and deterministic over time.

We should devise a proper and consistent naming scheme for image and kubernetes resource specifications that will not fail unexpectedly and that will support testing of branch-based naming for dev/test/alpha/beta/prod differentiation and that supports rolling updates of services in live environments.