I have the same issue when the latest build for Fedora 31 is correctly marked as an update for Fedora 31 but the name contains fedora26 which might be misleading for users.

https://bodhi.fedoraproject.org/updates/FEDORA-CONTAINER-2020-01f419245a

This is due to this commit [1]. The release was removed in favour of allowing the atomic-reactor bump_release plugin to bump the release. It does so by using some koji xmlrpc calls. To fix this, you will need to build one version for a specific release (e.g., 17), and then the bump_release plugin should take care of the following releases.

This is somewhat related to https://pagure.io/ContainerSIG/container-sig/issue/20, which seems to be a better approach to to identify containers in the NVR while allowing container builds to have the same name as the RPM counterparts.

[1] https://src.fedoraproject.org/container/s2i-core/c/93f1fe759091c69853d1db1d87cd62111f7d38dd?branch=master

To fix this, you will need to build one version for a specific release (e.g., 17), and then the bump_release plugin should take care of the following releases.

Thanks for the explanation. Could you please describe in a bit more detail how can I do this? Should I use --build-release for this?

1) Re-introduce the release label to the Dockerfile with a hardcoded release not present in koji (preferably an integer value).

2) Build the image

3) Remove the hardcoded release label from the dockerfile

4) For the next releases, OSBS will automatically bump your releases.

I can confirm this process described above works. There was also an idea to add some different, Fedora-version-agnostic suffix, e.g. something like 84.containers. The build system is clever enough to bump only the number. The benefit is that we can clearly distinguish what build is the container and what RPM build if the component is the same.

Do we have a tracker for this naming distinguishing approach? If not, we could start the discussion in a new issue. Finally, should we enforce it somehow?

Moreover, we could go through all the current image tags and provide PR with fixes for them on this issue before closing this ticket

I am still a little bit confused. I've tried to add a release label back for s2i-base on F32: https://src.fedoraproject.org/container/s2i-base/c/85e37db98721926232ceaf1b63522ef6e8e253ee?branch=f32

but then the build failed with "osbs.exceptions.OsbsValidationException: release label doesn't have proper format" - see https://koji.fedoraproject.org/koji/taskinfo?taskID=43799812

so I gave it another try without disttag in hope that osbs will add it automatically: https://src.fedoraproject.org/container/s2i-base/c/9b4236da8b62b96a544e0af7bb55567982ebe728?branch=f32

and the build succeeded but the container has no disttag: https://koji.fedoraproject.org/koji/buildinfo?buildID=1498496

When I was trying to find the right solution I went through available Bodhi updates and it seems that the only container with proper Fedora version in its name is fedora-toolbox but the fedora version in its name comes from $VERSION in its Dockerfile.

How the settings should look like to fix the problem?

Well, the proper way to show the fedora version of your image seeems through using namespaces with $FGC, which we may want to drop (https://pagure.io/ContainerSIG/container-sig/issue/2) to eventually be able to migrate to quay.io.

I can find no entries in the guidelines for the disttag in the release components of the images, and it seems we should just not include one.

@cverna, do you happen to know what is the current approach for this one nowadays? I can go ahead and update the guidelines after I have better understanding on where we want to head here.

This discussion here may also be relevant for this ticket:

https://meetbot-raw.fedoraproject.org/teams/container_sig/container_sig.2018-11-19-13.01.log.html

I remembered some discussions to know if the disttag was useful or not for container images, since in most cases you are interested by the version of the component you release and not so much by the base image.

I think we should use the container tags to specify what is the base image version, and example would be :

podman pull origin-base:3.11
podman pull origin-base:3.11.f32
podman pull origin-base:3.11.f31

How does that sounds ? Are disttags in koji needed ?

The tag is a good idea to solve the issue on the registry side, i.e., "What is the base for this image?" from a user perspective.

How would the version tag be updated? if 3.11.f32 is pushed with 3.11, then what happens if we push 3.11.f31 after that? In other words, how do we avoid 3.11 pointing to builds based on older Fedora releases?

We could have all images to explicitly specify their tags in container.yaml and only the image in the most recent Fedora release carry the VERSION ONLY tag.

I also have been trying to think about the koji components and what they mean for packagers. It would be easier to track them with the disttag in them, right? Moreover, it would be odd to have origin-base-3.11-1 as being a build for rawhide, and then origin-base-3.11-2 as being the f32 counterpart for the same build.

Instead, we could have origin-base-3.11-1.f33 and origin-base-3.11-1.f32. This would automatically solve the tag issue, since OSBS provides NVR tags for all builds. This is has been tried before, but then the users would have to keep setting the tags, and supporting autorebuilds is problematic.

What if we had a Fedora specific OSBS plugin to adjust the release to include the disttag (or adjust the current OSBS plugin in charge of setting the release for the image)?

The tricky part would be how to deal with autorebuilds. Should we enforce never using the latest tag and setting the tags to specific releases instead? This way an autorebuild would never happen with wrong releases. For instance, we do not want an image that was based on fedora:latest in the f32 branch to be rebuilt on top of f33 when it is out, do we?

How do we currently handle new fedora releases regarding the images? Is there any automation in place for mass rebuilds, setting proper base images, etc?

If this is an acceptable approach, I will go ahead and start writing the new plugin or make the proper changes in the bump_release one.