The goal of this thread is to bring about discussion on how we think about and use smart proxies in the Foreman architecture when building and designing. The impetus for bringing this up started with a PR designed to unify how the Katello plugin know about Pulp deployments. From the PR came two distinct opinions about how we should think about smart proxies. I want to try to come to a collective view of them to drive changes. First some background to understand what inspired the broader conversation.
Some brief background to help shed some light. Katello uses Pulp in two modes: master and child. The Pulp master is considered the source of all truth that the server talks to to create and manage all repositories that Katello knows about. A Pulp child is a remote Pulp that contains a subset of content in the Pulp master determined by assigning Lifecycle Environments to the Smart Proxy associated with the Pulp child. Today, in both cases a Smart Proxy is always associated with the Pulp deployment. The associated Smart Proxy serves to provide information Pulp does not directly such as storage usage. Further, and more importantly the Smart Proxy today is treated as the location of the Pulp. Katello treats the smart proxy installed on the server as the “default” and flag it as such. This nomenclature allows Katello to identify the Pulp master. One key difference is that in some areas of the code, Katello uses SETTINGS to define and reference Pulp attributes including the URL of the Pulp master. One key take away is that in SETTINGS Katello defines how to talk to the Pulp master and uses that in code, in some places Katello uses the Smart Proxy to define where Pulp is located.
Two Servers Diverged in a Smart Proxy
From the aforementioned thread, two opinions arose as to how to handle this difference and raised a broader architectural question. I will do my best to represent each opinion but @sean797 and @ekohl please correct anything I get wrong. As you read through this, be thinking about current deployments as well as forward thinking deployments where a Smart Proxy and a service are less co-located. For example, putting a database or Pulp on one server and a Smart Proxy on a different server. Or, a smart proxy container that is not at the same service address as the Pulp container.
Server is Server
This design principal is about letting the server be the sever, independent, and stand alone without the requirement for a smart proxy. In this concept, the server should be able to do everything it needs to do without having a smart proxy present. Smart proxies should then be used for remote operational management or scale out. If we relate this back to the original PR for an example, this would mean defining where the Pulp master is in SETTINGS at deployment time and using that to solely determine communication properties of the Pulp master. If a Pulp child is brought online near a datacenter, a smart proxy would also be installed that knows about the Pulp child and is able to relay information about it via a smart proxy back to the server. This provides a stand-alone, more lighter-weight server deployment that requires less to scale at the cost of potentially less discoverable service mechanisms and referencing remote servers in two separate ways.
I’m a Proxy, Let me Proxy
This design principal is about letting the Smart Proxy be a proxy and service discovery mechanism for all remote and backend services. Whenever a backend service is deployed, a Smart Proxy would need to exist somewhere that knows about where the service is located at and properties of the services deployment at a minimum. Taking the PR example, this would mean continuing the current usage of a Smart Proxy, requiring one on the Server and using it too inform Katello about where Pulp lives and other properties. Deployments would require a Smart Proxy to tell the server here is where the Pulp master or child is and information about it. This provides an abstraction and single point of contact for information about a remote or backend service uniformly within the application at the cost of always requiring an additional smart proxy service running somewhere.
First, I referenced a specific Katello scenario due to the PR that inspired this conversation but devs should expand their thinking to all usages of the Smart Proxy today and how one way or the other could shift those interactions. Secondly, within the container work this issue and the PR that sparked the conversation represent a functionality breakage that I can’t fix without resolving this discussion. Therefore, I will do my best to keep the conversation flowing, recapped and try to come to a solution in a timely manner.