We’ve made some designs for adding push functionality to our container registry and I would like to share it with you all.
For some background, currently, in Katello, you can sync “container repositories” and interact with them using podman/docker. While we allow you to upload manifests and retag them with Katello, we have no support for
podman push. With
podman push you can create your own container manifests, tag them, and deliver them to the container registry.
Pulp 3 implements
podman push support using something called “push repositories”. Rather than push container content to an existing repository, a user pushes to the Pulp container registry and a new repository is created under-the-hood in Pulp. If a user pushes to an existing repository, then the old push repository is used and a new repository version is generated. There are a couple caveats though:
- Content is pushed to a push repository type. A push repository does not support mirroring of the remote content via the Pulp API.
- Rollback to the previous repository versions is not possible with a push repository. Its latest version will always be served.
So, content in these push repositories require special handling.
Here’s the design in short:
- A user initiates the sequence by pushing content to Katello’s registry.
- Katello ensures the user is allowed to push content and then redirects the request to Pulp.
- Once Pulp has created the push repository, Katello finds it and copies the contents to a normal container repository.
- Katello creates a product and a repository as necessary and associates the new Pulp repository to it.
- Katello distributes the new Pulp repository and follows the custom container repository naming scheme if there is one set.
- The user interacts with the new repository just like any other container repository in Katello.
Now here are some details:
How will Katello know if a user is allowed to push content?
A user can have varying kinds of access to creating repositories in Katello. At the most basic level, Katello will need to know what Organization a user is pushing to. So, we’re proposing to use a sort of namespacing system:
- If a user wants to push to an Organization’s auto-created container push Product (this is part of the new design), they’ll do something like:
podman push <image ID> docker://foreman.example.com/My_Org/busybox:latest
- If a user wants to push to a specific product:
podman push <image ID> docker://foreman.example.com/My_Org/My_Product/busybox:latest
The user details should come along in the headers, so we shouldn’t have to have users push with their username in the command itself.
How will pushes to the same repository work?
Assuming that the Pulp registry returns no information about the container push repository that is created at push time, Katello will find and use the existing container push repository. We’ll just need to run another copy command to bring over the new contents, reindex the repository, and redistribute it.
How will Katello handle the old container push repositories?
When a repository is deleted, the related container push repository will be deleted as well.
How will authentication work?
Just like with
podman pull, a user will first
podman login and go from there.
Will there be smart proxy support?
Only via smart proxy syncing. We’re only targeting
podman push for the main Foreman+Katello instance. A smart proxy mirrors what’s in Katello, so users can perform a smart proxy sync to get their push repositories onto their smart proxies.
If anyone is curious, I have a PoC branch that allows for pushing content to Pulp through Katello’s registry proxy. I’m still figuring out Pulp’s tokenless authentication for pushing, so in the meantime, you need to comment out some of Pulp’s auth code to test.
There are certainly some details that I’ve left out, so please ask questions if you have any. Now is the time to get concerns sorted!