First, thanks everyone that has participated in the conversations thus far. One of the goals of posting these RFCs was to engage the community in discussion to help arrive at a direction that makes the most sense and this discussion helps. I am going to clarify (I hope) one idea @TimoGoebel mentions here but was refined in IRC conversation as a proposal for some feedback.
One commentary heard through this discussion is around how to get the community comfortable with containers. That is how do we get comfortable operating, building, debugging and understanding just the container aspect rather than the full blown container ecosystem. To this end, the question has been raised could we focus on building containers and replacing existing proccesses with them. For example, currently the default Foreman install runs under Passenger within Apache. This could be replaced by a container running on the host with Apache handling SSL and doing a reverse proxy. The idea being this lets us focus on building containers and running them without changing the overall installation dramatically. This stepping stone approach could be propagated across the set of services and in theory provide a gateway to then move those containers into Kubernetes. This would not necessarily provide us the out of the box HA/Load-balancing gains that Kubernetes could give us but would be targeted at stepping the community that direction while aiming towards reduction of packaging burdens as one benefit.
The reduction in packaging burdens being from focusing on building containers using source and native dependency managers (e.g. gem, npm) which would drop the requirement for packaging both Deb and RPM.
This approach would obviously be a slower transition given we’d want to provide incremental value and changes between each release.
One target of this work has been how to handle migration of Katello to Pulp 3 in a staged approach moving content types one by one and thus running and supporting both for a time being. Given the potential to clash, the RPM effort for Pulp 3, one idea had been to put Pulp 3 directly into Kubernetes to start with and thereby keep the two apart. There is an open question whether the above approach helps with that or provides the same issues that native processes would.
Please consider the above, and the original idea and provide any feedback you can around this approach.