search

projectatomic / ContainerApplicationGenericLabels

Default Containerized Application Labels used to document the application and/or image
68 stars 29 forks source link

Reason to have "name" label? #48

Open mfojtik opened 8 years ago

mfojtik commented 8 years ago

What is the reason to have the name label if it matches with the image name? Both OS and Kubernetes have display-name label which provides more information in human-readable form about the image content. For example: https://github.com/openshift/sti-ruby/blob/master/2.2/Dockerfile#L13

TomasTomecek commented 8 years ago

We use this in build service to construct image name. Name of dist-git repo is different from name label b/c label may contain slashes. Also you may obtain an image as an archive and it's good to know its desired name and origin.

mfojtik commented 8 years ago

@TomasTomecek how do then set the "name" label when doing Docker build? How is that different from tagging the image with that name?

TomasTomecek commented 8 years ago

Here's the workflow:

  1. Create dockerfile; set name, version, release labels by hand
  2. Submit build
  3. Koji constructs NVR of the build from labels like this: ${com.redhat.component}-${name}-${version} (don't ask, it's the way koji works)
  4. build the image using some ugly name (we want to change this so the name is prettier)
  5. tag the built image using name, version, release labels and push it to registry

This can be changed/updated of course. It's just what we use now.

mfojtik commented 8 years ago

@TomasTomecek when you tagging the image, can you change the image name instead of adding the name tag? I think I understand the use-case you have, but that label seems redundant to me long term.

TomasTomecek commented 8 years ago

I think there is slight misunderstanding here: without name, version, release labels, build system has no idea how to name/tag the image. The only information it has at that time is com.redhat.component label which is name of component within bugzilla, e.g. rhel-server-docker and that is for images named rhel{6,7}.

So, we could get rid of the label, but we would have to find new way how to get final image name. Basically a mapping between com.redhat.component, branch within git and the final image name.