search

radanalyticsio / openshift-spark

72 stars 83 forks source link

Change the tagging of x.y-latest to just x.y #102

Closed tmckayus closed 4 years ago

tmckayus commented 4 years ago

We tag images with x.y.z, and have a movable x.y-latest tag that references the most recent x.y.z. Change the convention and drop the -latest, just creating a movable x.y.

This will help deprecate some existing tools that rely on x.y-latest, so that those versions will be effectively frozen.

tmckayus commented 4 years ago

@jkremser @elmiko ptal

This will help decouple oshino-cli from openshift-spark updates. Currently oshinko-cli is referencing x.y-latest, and as soon as openshift-spark is updated, the spark version in oshinko-cli moves.

erikerlandson commented 4 years ago

We actually a scenario a couple weeks ago where the ODH jupyter image tag was moved to a new image, and it broke a deployment. The pod had already resolved to a particular SHA, and then it restarted and that SHA was suddenly no longer there.

As I understand it, best practice is to never remove tags, or move them once they're assigned. So maybe full sem-ver x.y.z, and if you have a new one, just bump 'z'.

clasohm commented 4 years ago

We actually a scenario a couple weeks ago where the ODH jupyter image tag was moved to a new image, and it broke a deployment. The pod had already resolved to a particular SHA, and then it restarted and that SHA was suddenly no longer there.

As I understand it, best practice is to never remove tags, or move them once they're assigned. So maybe full sem-ver x.y.z, and if you have a new one, just bump 'z'.

Looking at the Quay documentation, I think what happened is that the "latest" tag for jupyterhub-img was moved to a new image. The previous image did not have any tags assigned to it anymore and was therefore deleted by Quay.

To prevent this and preserve old image versions that might still be used by existing deployments, we could use multiple tags, see https://access.redhat.com/containers/?tab=tags#/registry.access.redhat.com/ubi7 for an example.

The newest image would be tagged with x.y and also with x.y-z or x.y.z. When an updated image is added, the x.y tag would be moved to the updated image. The x.y.z tag remains unchanged, and the new image would get a new x.y.z2 tag.

Deployments, Dockerfiles and BuildConfigs should only reference the x.y tag, never the x.y.z tag.

tmckayus commented 4 years ago

We actually do use multiple tags. All of our builds are x.y.z, like 2.4.5, but some tools like oshinko are using 2.4-latest. I'm just suggesting dropping "latest" here in favor of "2.4" so that we still have the historical convention of a movable tag for the tip of the major minor version but leave the tools frozen.