Dotnet-docker: Feature request: provide immutable docker image tag options

[ryanwalls]

Currently, all image tags on docker hub seem to be candidates for updating in place. e.g. the microsoft/dotnet:1.1.2-sdk tag was updated with a new image 2 days ago that broke our production deployment pipeline.

Ideally the project would provide tags that are immutable once pushed.

Currently the tags look like this:

1.1.2-sdk-jessie, 1.1.2-sdk, 1.1-sdk, 1-sdk

I would propose keeping all those tags, but also adding immutable tags for each image push, like:

1.1.2-sdk-jessie-v.1

Then when the need arose to "push a new image for 1.1.2" you could tag the new immutable image as:

1.1.2-sdk-jessie-v.2

And then update all the other tags "in place" if you so chose.

[pkrull]

+1

[alexDrinkwater]

+1

[richlander]

A few of us talked. Here is our plan.

• Remove the 1.0.5-sdk image (and friends). It is the same as the 1.1 SDK image. Now that 1.1 is LTS, this tag doesn't seem needed. The CLI version is the same in both cases.
• Version the the 1.1 SDK image in terms of the 1.1 SDK version number not the 1.1 runtime.
• Update the 1.1.0 SDK (the SDK itself, not the Docker tag) to 1.1.3 next time it ships, which will perfectly map to the next Docker tag, which would be 1.1.3-sdk.
• Enable the runtime and SDK to go out of sync and then artificially catch them up at appropriate opportunities.

This last point is the key policy choice that will fix this issue going forward. It is already what we had planned for 2.0. 1.x was more challenges because of the "two runtimes, one SDK" challenge. If we switch the 1.x SDK to being just a 1.1 deliverable, then the Docker tags can be sane. Our other approach was to start publishing the following tags:

• 1.0.5-sdk-1.1.0
• 1.1.2-sdk-1.1.0

I won't explain what these are intended to communicate, because if you cannot immediately figure it out, it proves that this other plan is a bad idea. ;)

Please give feedback.

[omajid]

Remove the 1.0.5-sdk image (and friends). It is the same as the 1.1 SDK image. Now that 1.1 is LTS, this tag doesn't seem needed. The CLI version is the same in both cases.

That might break the workflow of users currently using this tag. Would it be possible to keep it but maybe not document it? More importantly, what about 1.0-sdk? Does that get obsolete too? Maybe look into tagging one image as both 1.0-sdk as well as 1.1-sdk?

But going back to the original user reports, I am really confused. The request was for immutable tags, and no more in-place updates. Unless I am missing something, the proposal does not address that request at all.

[ryanwalls]

@richlander I've read your comment a few times, and I think I'm missing some information about the future of versioning on dotnet core, so I can't fully grasp what you are proposing. Specifically, I don't understand this line:

Enable the runtime and SDK to go out of sync and then artificially catch them up at appropriate opportunities.

However the team decides to proceed, I just ask that a set of immutable semver compliant docker tags are used and documented.

i.e. They follow rule 3 of semver, "Once a versioned package has been released, the contents of that version MUST NOT be modified. Any modifications MUST be released as a new version." http://semver.org/#spec-item-3.

[MichaelSimons]

@ryanwalls - Our intent is to rev the image version number whenever a .NET Core component changes (e.g the Dockerfiles used to produce the images are changed). The images however get rebuilt automatically when a new base image is available. For example whenever debian:stretch is patched, the .NET Core images get rebuilt with the new base image. If you truly want an immutable tag, then it seems using a digest would be the solution.

[MichaelSimons]

@omajid

That might break the workflow of users currently using this tag. Would it be possible to keep it but maybe not document it? More importantly, what about 1.0-sdk? Does that get obsolete too? Maybe look into tagging one image as both 1.0-sdk as well as 1.1-sdk?

By 'Remove' @richlander's intent was that the tag is removed from the documentation. New images would get multi-tagged with the old tags so as to not break existing usage just as you suggested.

[bradwilson]

So, I just got bit by this with 2.1.2, and frankly, the policy decision here is garbage.

I asked for microsoft/aspnetcore-build:2.0.3. There was no hint that 2.0.3 meant anything other than SDK, because frankly, what _should_ it mean in the context of build? It is 100% "the SDK version" in the head of anybody looking at that version.

What's worse is @natemcmaster tells me that the way to fix this is to request microsoft/aspnetcore-build:2.0.3-stretch, which is adding _only_ information about the Debian version, but somehow now magically sticks me onto the 2.0.3 SDK, where is where I should've been all along.

NOBODY UNDERSTANDS THIS OUTSIDE OF YOUR TEAM. You couldn't have possibly chosen a more incorrect way to do this.

[MichaelSimons]

@bradwilson - I'm not sure I follow you. What SDK are you looking for?

[bradwilson]

2.0.3

[MichaelSimons]

@bradwilson - apologies - the 2.0.3 tag (a manifest backed tag) was incorrectly updated today. The underlying issue was corrected and the image was updated.

[ryanwalls]

@MichaelSimons Feel free to close this if you feel this issue is now addressed with the new tagging scheme.

[richlander]

FWIW ... We are trying very hard to apply Docker norms to dotnet repos. We believe that we've changed our tagging to align with the requests of this thread.