This investigation is looking into service `quay.io <https://quay.io/>`_ and how can we utilize
it for the projects hosted on `registry.fedoraproject.org <https://registry.fedoraproject.org/>`_. It should also resolve if this is work should be initiative.
* Multi Arch containers (Already supported on quay.io)
* OCI images (Already supported on quay.io)
* Web interface (Quay.io already has web interface)
* Integrate Quay.io in current workflow
* Must not affect users of images
*`candidate-registry <https://candidate-registry.fedoraproject.org/>`_ must be moved as well
Nice to have
------------
* Staging namespace on quay.io
Risks
-----
* There is a `pull rate limit <https://docs.quay.io/issues/429.html>`_ per second on IP address on quay.io. This could cause issues in the future, but current load should be easily handled.
Investigation
-------------
The investigation is separated to multiple parts based on the current artifacts hosted on registry:
* Step 1 - Create namespaces corresponding to candidate-registry and registry on `quay.io <https://quay.io/>`_ (Optional: Create staging namespaces as well)
* Step 2 - Modify configurations and scripts (see corresponding investigation document for what needs
to be changed)
* Step 3 - Redirect proxies to `quay.io <https://quay.io/>`_
* Step 4 - Decommision `candidate-registry <https://candidate-registry.fedoraproject.org/>`_ and `candidate-registry <https://candidate-registry.fedoraproject.org/>`_