I feel somewhat qualified to weigh in here. It’s not just the MongoDB removal but rather the whole architecture of Pulp 3 that’s much better suited to scaling out. And it’s not just Pulp 3 but what I’ve also tried to focus on is how you configure things. For example, Katello is slowly learning to properly direct clients to the correct URLs. This helps with splitting things up.
Concrete example: Katello used to assume that the hostname in the Smart Proxy URL was also the hostname in the content URL. It now learns the URL from the Smart Proxy configuration. This allows multi homing and/or splitting: you can run the Smart Proxy on
sp-nnn.mgmt.example.com but direct clients to
pulp-content.example.com. As I always said during the design phase: it should be possible to run Pulp in a Kubernetes(/OpenShift) cluster and have a Smart Proxy just to point at it.
And on a similar note, we’re laying the ground work for doing the same thing with the subscription service.
So while not directly targeted at containerizing, I strongly believe we must build for HA support to really support a containerized deployment. That’s why I’m trying to decouple services and prepare designs for such a world.
Another thing that I worry about are properly dealing with failure modes. What if a service is unavailable? Right now a lot is built with the assumption that a backend service is available. This is also why upgrades often work best with the blunt “shut down all services, upgrade, start them up again”. In a containerized world that is probably a lot harder.