Right now, a container image maintainer must provide by hand a VERSION label, in the 2017-03-10 VFAD it was decided that we will use a "Version 0" for now until we have the ability to automatically populate an image name via some kind of macro entry or an AUTOPOPULATE_VERSION label that's a non-zero length string (or similar) in the Dockerfile that is substituted within the build system to correlate the container image version with that of the main RPM it's meant to deliver.
Metadata Update from @maxamillion: - Issue assigned to maxamillion
Metadata Update from @dustymabe: - Issue tagged with: containers
https://taiga.fedorainfracloud.org/project/acarter-fedora-docker-atomic-tooling/us/778
For images like mariadb, I'd like to set the version to major version (e.g. 10.1), which is what users care (take a look how tags look like on docker hub). Such major version is different than RPM version (e.g. 10.1.23) and also does not change often. When it changes, we usually need to do more changes, so updating the Dockerfile even by hand is not a problem.
So, long story short, why not to allow defining version label to something meaningful if maintainers wish so and are fine with manually updating it?
Is there any update on this?
I think that a tag showing the version of the component is very useful. I discover this need when using kubernetes components. When you pull images like kubernetes-kubelet or even etcd you may need to pin down to a specific version. eg the google_containers have tags with the corresponding version.
gcr.io/google_containers/hyperkube:v1.5.3
for containers from the fedora registry we could have
registry.fedoraproject.org/f25/kubernetes-kubelet:v1.5.3
I know that kubermetes is installed from the fedora repos inside the container and we don't set explicitly the version and when you pull the new images you get the latest. IMO, we need the version because, in some cases you may update to the latest kubernetes-kubelet image and get the up to date image with the same kube version and in some cases the version might change. One might want to update only if the kube version is the same or he might want to rollback. Another example is when a package is broken and you need to revert, you might want an updated fedora base but the previous component version. I had this issue with etcd. I wanted etcd 3.0.15 because there was a bug in 3.0.17 and with the fedora image I was getting only 3.0.17.
What do you think?
Currently I am busy with higher priority work, most notably I am working with upstream on the OSBS Orchestrator and Worker Cluster Split as well as the OSBS Automatic Chain Rebuilds. This ticket is likely to not get development attention from myself until at least August. If someone else would like to work on this, I would be happy to provide feedback and/or guidance and will also drop myself as the ticket assignee.
I made a ticket to talk about this issue in the kubernetes context in https://pagure.io/atomic/kubernetes-sig/issue/6
Metadata Update from @cverna: - Issue assigned to cverna (was: maxamillion)
I have open a ticket on koji-containerbuild[0] to discuss with the OSBS team how to implement this feature.
[0] - https://github.com/release-engineering/koji-containerbuild/issues/95
Thanks @cverna !
@cverna is this done now?
I don't think there way any code written for this: https://github.com/projectatomic/atomic-reactor/issues/963
Login to comment on this ticket.