Docker Image for ubuntu/bind9 tagged incorrectly

Bug #1955318 reported by Terrence Houlahan
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Ubuntu Docker Images
Opinion
Medium
Unassigned

Bug Description

The Docker image for "ubuntu/bind9" are all the same: "latest", "edge", "9.16-21.10_beta" and "9.16-21.10_edge".

"mitechie" pushed image "9.16-21.10_edge".

Then "sergiodj" followed behind the committer "mitechie" and pushed the same image under the tags "latest", "edge" and "9.16-21.10_beta".

ALL the images have the same SHA256 hash.

Further, the "edge" channel has been deprecated for several years.

And none of the images are signed.

So "Edge" is between "Test" and "Stable", but "Edge" hasn't existed for years.

And "9.16-21.10_beta" is tagged the same as "Edge".

A "beta" is the same quality as "edge"?!?!?

This is a total mess and the tags are meaningless.

"Edge" is a long since deprecated channel and giving a "beta" release the same quality assurance of a higher- but non-existent- channel makes no sense at all.

The fact that none of these images are signed given all this confusion leads to further uncertainty as to using them.

We need some clarity here on what's going on with ubuntu/bind9 please ...

Revision history for this message
Valentin Viennot (valentinviennot) wrote (last edit ): Re: [Bug 1955318] [NEW] Docker Image for ubuntu/bind9 tagged incorrectly
Download full text (3.7 KiB)

Hey there,

Thanks for your feedback and interest in our Ubuntu-based BIND9 OCI image <https://hub.docker.com/r/ubuntu/bind9>! I'm Valentin, the Product Manager for these Ubuntu-based container images with a maintenance commitment from Canonical.

Let me address your comments separately.

First, on the "edge" to "stable" risk information:

We decided to tag our images using the following scheme - "X.Y-A.B_risk", where "X.Y-A.B" is what we call a "track".

The track identifies the application version delivered (X.Y) and the base image used to deliver it (A.B). That way, it's super easy to track maintained software versions and get alignment in your dependencies.

The "risk" gives maturity information about the tagged content. An "edge" channel will represent a higher risk than "beta", "beta" than "candidate", and "candidate" than "stable". This scheme is meant to represent the lifecycle of software components,
- from a version still under active development ("edge"),
- to a version under user testing ("beta"),
- selected for stable promotion ("candidate"),
- and finally, a version that is under vendor maintenance and won't receive more than security fixes ("stable".)

We require you to explicit the risk you're accepting by specifying it in the image tag. It makes it very clear in your deployments what version you're using. You won't ever receive something riskier than your explicitly requested risk.
A good read: https://snapcraft.io/docs/channels#heading--risk-levels.

On the multiple tags pointing to the same content (i.e., same hash):

I am sorry this seems confusing on your side; feedback taken. In OCI registries, images are available to download in 3 different ways:
- no tags, 'latest' implied, for development purposes,
- using an image tag, i.e. a dynamic pointer,
- utilising the content hash, e.g. SHA256, to access specific content.

The hash to tags relationship is a one-to-many kind. It is usual that many tags could refer to the same hash. The tag is only a reference.

Think about the "X.Y-A-B_edge" channel; it will receive frequent updates (i.e. new hashes/SHA256). Using the tag, you will roll to the latest development version.
From the "X.Y-A-B_stable" channel, you're guaranteed that we won't send breaking changes. However, using "stable" channel tags will automatically benefit from the latest security patches applied.

Now, why does "edge" and "beta" point to the same content? "Is "beta" the same quality as "edge"?" Good question.
The answer is: No, It's the other way. "Edge" is now the same quality as "Beta". The software matured, we decided to move it to "Beta", and the users who explicitly accepted the riskiest level ("Edge") will now receive a more stable image. Usually, a newer track with the latest software will become available on a different "Edge" channel. You can manually switch to it (in fact, upgrading versions).

(This is explained in https://hub.docker.com/r/ubuntu/bind9#tags-and-architectures.)

Finally, on the images not being signed:

100% valid, and it's on our roadmap. We currently provide all the images under the "Ubuntu" namespace as "Beta" content for our community to experiment with freely and provide feedb...

Read more...

Revision history for this message
Olivier Duclos (odc) wrote :

Hi,

On this subject, I noticed none of the ubuntu/* docker images have a "stable" version. Why is that? When do you expect to publish stable releases?

Changed in ubuntu-docker-images:
assignee: nobody → Athos Ribeiro (athos-ribeiro)
Changed in ubuntu-docker-images:
assignee: Athos Ribeiro (athos-ribeiro) → nobody
Revision history for this message
Valentin Viennot (valentinviennot) wrote :

Hey odc, apologies for the late reply! This will come soon, with a few considerable changes (ie, not exactly the same images as you are currently using).

Closing this issue

Changed in ubuntu-docker-images:
status: New → Opinion
importance: Undecided → Medium
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.