This has been broken out from the original RFC in order to provide focused discussion.
Smart Proxy vs. Foreman Proxy vs. Foreman Proxy with Content
Within just Foreman, there are two similar concepts:
- smart-proxy the software, with plugins
- foreman-proxy the RPM and Debian packaging and deployment convention
- Smart Proxies are used in UI concept and API
When Katello enters the picture, further concepts get added:
- Foreman proxy with content to represent a slew of functionality
- content services
- reverse proxy for host communication
However, other plugins also bring along additional software and features:
- REX with Ansible brings ansible-runnner
- Dynflow to manage orchestrating of jobs
Generally, I am proposing that we define and name the entity that conceptually encompasses the additional component that a user might deploy to manage a set of external services or provide isolated services to a set of hosts. And that this entity, remains separate conceptually from the software component known as the smart-proxy that is the underlying technology given that there are at times features of this entity that are not connected to or controlled by the smart-proxy. Giving this entity a name that we can reference universally across the community will help with building both software components as well as enabling clearer communication to users and among developers.
The alternative is to drop foreman-proxy naming and centralize on the use of Smart Proxy as both the software and the concept. This can be easier from a code perspective, and will push to ensure that every feature deployed has a corresponding smart proxy plugin/feature for reporting. This also aids in maintenance of the entity. The nomenclature would then be to talk about a Smart Proxy with Features X/Y/Z. I know in the past that the ‘smart proxy’ naming convention has not always been well received and often confused by things like HTTP proxies.
From a deployment and management stand point, users install a Foreman server, most often with a smart-proxy as the base installation. Then as they need to either manage a service, provide a gateway at a network edge, or scale out they start to deploy a Foreman with a smart proxy and some number of additional services running alongside based on feature set.
For me, this mirrors a lot of other software out there that is very popular these days: Kubernetes, Jenkins to name a couple.
To seed some naming ideas:
- Foreman Node
- Foreman Capsule
- Foreman Site
- Foreman Portal
- Foreman <insert construction term here>