The smart-proxy has been designed to provide restful API to subsystems and serve as a form of service discovery for those subsystems. As a project, we are seeing the smart-proxy being looked at for providing client facing services. This has the potential to place additional performance pressure on the smart-proxy. This RFC is aimed at identifying the efforts that will result in more traffic through the smart-proxy, and starting a discussion on overall trend design, and efforts we need to undertake to ensure that we pro-actively ensure the smart-proxy can handle these changes.
I intend to take several tactics to help with these discussions and identification of work. The first of these is this post asking the community of developers, and users, to discuss changes needed on the smart-proxy, peformance concerns, re-factorings, simplifications and concerns with this trend. The fundamental question is whether this trend to using the smart-proxy more is the right direction. Second to that is what core changes we need to under take to ensure this increase in usage of the smart-proxy is successful. Additionally, I will schedule some face-to-face SIG style discussions to make decisions and resolve issues syncronously where needed.
From a non-technical stand point, pointing more features, more concerns and more developers at the smart-proxy is a good thing. The smart-proxy has historically had a single maintainer at any time, and a tiny sub-set of active developers who understand the code and design of it’s sub-systems. The more use cases we have for the smart-proxy, the more developers we have building and maintaing it, the better for such a critical piece of the Foreman infrastructure. Further, this can help to bridge some long standing gaps we have with Foreman vs Katello installations.
Current features targetting smart-proxy
If you are currently working on a feature that intends to place additional traffic and pressure on the smart-proxy, please respond with what that feature is and any links to design information to aid in these discussions. The list will get updated, with the current list of on going features:
Identified re-factoring and core design work
Key Open Questions
- Is the smart-proxy the right place for client facing actions (e.g. global registration, remote execution job fetching and status, container auth, subscription-manager proxying) ?
- What architectural changes are needed to the smart-proxy to support increased traffic?
- What should be our scaling guidelines for smart-proxy deployments based on deployed features?