Container image names are created automatically as images are managed through their products, content views, and lifecycle environments. These names, while cumbersome when manually using, are predictable and are referenced in tooling (such as CI/CD pipelines and Dockerfiles). The format is a combination of the labels: $organization-$lifecycle-$contentview-$product-$repo.
For example, to reference an image with the tag 2.6 in the organization "examplecorp", in lifecycle environment "development", in the content view "alpineos", in the product "dockerhub", in the repository "alpine": docker pull examplecorp-development-alpineos-dockerhub-alpine:2.6 There are documented restrictions on the naming[1] and that is where the problems begin. The rules are currently enforced in pulp as it manages the repos. The labels for the named components in Foreman are often auto-suggested (and accepted) with defaults based upon the name. For example, a name of "My Organization - Number: 1" would get an auto-suggested name of "My_Organization_-_Number__1". The resulting image name would, after forced downcase internally, be "my_organization_-_number__1". This name would be rejected by pulp for any container image repos. Since labels cannot be altered after creation, this would be quite painful for anyone that added image repos without knowing and honoring the docker naming restrictions up front. Pulp does allow the modification of the names exposed via the registry. This feature is not exposed in Foreman but doing so would allow names to be corrected or updated at any time. The most intuitive way, may be to allow a custom container image name to be assigned to the various components. This would prevent being blocked by rules discovered too late in the process. In addition, I would like to push this concept even further by saying that the component names be optional and that the joining character (now an underscore) be configurable as well. A basic use case for syncing images into Foreman is, "As a user, I want to mirror an external registry to make available internally." What happens now is that after mirroring, a Dockerfile that originally started with "FROM rhel7/rhel" now must be changed to "FROM examplecorp-production-webserver-rhel7-rhel7_rhel". Instead I'd like to have a way to indicate that "In organization examplecorp the production lifecycle environment should not prefix container image names but instead use the base repository image name." Thus, I could keep "FROM rhel7/rhel". (Yes, there would need to be more design on aspects of validating namespaces and such so just consider this a simplistic example.) This may seem insignificant but it would make using Foreman as a registry mirror very easy to integrate with other tools. So overall, I am asking if it would be acceptable to expose more container image specific info at the top level rather than confining it just to the "repos of docker type". Effectively adding a new field to orgs, lifecycles, and content views, and products. Sending this query to the users email list to see if three is yes, no, or don't care feedback. Devs, let me know your tech thoughts too. Thanks! Tom [1] https://github.com/docker/distribution/blob/master/docs/spec/api.md#overview -- You received this message because you are subscribed to the Google Groups "Foreman users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/foreman-users. For more options, visit https://groups.google.com/d/optout.
