RFC: Smart Proxy, Foreman Proxy, Foreman Proxy with Content

[ehelms]

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

Conceptual

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

Proposal

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>

[John_Mitsch]

Having the same name “Capsule” as Satellite would be a big help any time we need to refer to the Foreman Proxy. It also helps if we have any CLI tools or options that contain the name. So standardizing on “Capsule” has my vote

[lzap]

In the new documentation which we are working on based on Red Hat Satellite docs, we use two terms:

• Foreman Server (downstream this was Satellite Server)
• Foreman Smart-Proxy (downstream: Satellite Capsule)

I have just installed the first drop of 2.1 to get into SELinux issues and I have realized the new puma service is simply named foreman.service. I think this does not represent the service itself well on something we call Foreman (or Foreman Server) deployment and it can be confusing when foreman-capsule (or whatever name we choose) is installed alongside.

For the sake of simplicity and easy understanding for users, I vote for Foreman Capsule and Foreman Server as the terms for deployments as well as services: foreman-server and foreman-capsule.

[ekohl]

I always think of Capsule as a concept. Foreman Proxy is a part of that, as is Pulp and Apache. Together they provide a set of features. Renaming foreman-proxy to foreman-capsule is IMHO not a good idea.

I actually want to break up the capsules. You should not assume all functionality is always there. It really doesn’t make sense to me to deploy all features on a smart proxy every time. Rather insane IMHO to install a Puppetserver, Pulp, DNS and DHCP as well when all you need is REX. Having a monolithic concept of Capsules is harmful.

Another difference is that in the Foreman world, all you connect to is the Foreman Proxy. In Katello you also talk directly to Pulp.

One thing I always disliked is that Katello has a concept of an internal proxy. People see a Capsule as a different thing than Satellite. Often they don’t know how to debug foreman-proxy on the Satellite server even though it’s the same process running the same software.

I actually think we do not need to rename the software and the daemons. Capsule should be a deployment scenario of various software that includes a Foreman Proxy. The default server deployment is one that includes a Foreman Proxy.

[lzap]

@ekohl

I always think of Capsule as a concept. Foreman Proxy is a part of that

I agree, my understanding is the same. But I also see this as an opportunity to get rid of I think confusing term: Foreman Proxy (or Smart Proxy). This process has never been proxy in the generic understand of what proxy is. It’s a service that does many things, http (application) proxy is one of them.

@ekohl

I actually want to break up the capsules

Hmm, then using Capsule for Foreman Proxy term could be harmful.

@ekohl

I actually think we do not need to rename the software and the daemons. Capsule should be a deployment scenario of various software that includes a Foreman Proxy. The default server deployment is one that includes a Foreman Proxy.

With your argument of splitting up Capsule into individual services, I agree.

[ehelms]

@ekohl

The default server deployment is one that includes a Foreman Proxy.

This is one of the confusing aspects of our current nomenclature. When you reference Foreman Proxy, are you referring to:

• The host that contains a smart proxy
• The smart proxy itself
• The foreman-proxy package and daemon
• The concept of a smart-proxy plus some number of managed services

@ekohl

I actually want to break up the capsules. You should not assume all functionality is always there. It really doesn’t make sense to me to deploy all features on a smart proxy every time. Rather insane IMHO to install a Puppetserver, Pulp, DNS and DHCP as well when all you need is REX. Having a monolithic concept of Capsules is harmful.

And this is part of the prompting for my RFC. What do we call a smart-proxy + services? Do we have different names for each? Do we talk about it as a smart-proxy with X,Y,Z capabilities? Do we call it a foreman-proxy? What is the difference between smart-proxy and foreman-proxy?

@ekohl

One thing I always disliked is that Katello has a concept of an internal proxy. People see a Capsule as a different thing than Satellite. Often they don’t know how to debug foreman-proxy on the Satellite server even though it’s the same process running the same software.

This gets to the difference between the software and the concept. Capsules in Satellite land represent a feature set, a set of capabilities, a scale out mechanism. There are workflows where it is beneficial to know the “onboard” smart proxy. This was originally tied to really to just knowing which smart-proxy backed the Pulp master as that has to be treated differently than a Pulp mirror. We now also have the need for being to lock running REX jobs to the smart-proxy on the server.

[viwon]

One thing I would like to see is to add full API forwarding functionality to the smart proxy.

Today on our remote disconnected networks in order to allow clients on that network to do some things like register themselves and use some of regular foreman API calls that are not part of the smart proxy modules, I have to setup an nginx proxy on the smart proxy on some port like 9443 and proxy back to the Foreman server 443, so they can use things like /api/v2/hosts/ from the disconnected network.

I would be nice if the smart proxy had a built in ability to proxy those api calls back to foreman through its existing communications and eliminate the need to manually setup nginx proxy on the smart proxy in order to provide that function.

[Marek_Hulan]

@lzap

But I also see this as an opportunity to get rid of I think confusing term: Foreman Proxy (or Smart Proxy). This process has never been proxy in the generic understand of what proxy is. It’s a service that does many things, http (application) proxy is one of them.

+1, this is one of the things that can help new users understanding the project better. At the end, I don’t really care about the name, but I’d like us to:

• make it less confusing, don’t use the word proxy in it
• it does not matter to me, if it’s construction related name, it should be unique term everyone will use when we refer to it
• find the name for the concept but also for the core project, e.g. if we call the concept backman, it would be very confusing to install foreman-proxy rpm built from smart-proxy repo

For the record, I like all names from the first post except for “Foreman ”

[ekohl]

@Marek_Hulan

if we call the concept backman

I actually really like this name. Certainly made me laugh.

[lzap]

@ehelms

Foreman Node

Nodes are often used in the context of cluster, which is not our use case.

@ehelms

Foreman Capsule

I like this one, but as @ekohl said this could actually create new level of confusion.

@ehelms

Foreman Site

I kinda like this one the most. It encapsulates the meaning and the context nicely. A site can be anything, the master site, remote datacenter, branch office or even just a local unrouted subnet.

@ehelms

Foreman Portal

My kiddo would likely pick this one, but the moment I hear a term from Minecraft I hear my son explaining me some details about this world I haven’t asked for and I tend to close my ears for a moment

I know this might be too long, but how about:

• Foreman Site Server - the new term for deployment. Capsule today.
• Foreman Site API - the new term for smart-proxy.
• Foreman Site - the term for use when it does not really matter what you mean exactly.

Just for quick look downstream: Satellite Site Server, Satellite Site API. Hmmmm. SSS.

Maybe, for comparison:

• Foreman Capsule Server
• Foreman Capsule API
• Foreman Capsule
• Satellite Capsule Server
• Satellite Capsule API
• Satellite Capsule

Hmmm. I dunno.

[tbrisker]

Lets call it Foreman Bikeshed and be done with it

[quba42]

Having written a lot of (orcharhino) documentation I have struggled with the Smart Proxy, Capsule, etc. nomenclature and feel I need to add my two cents.

First of all, I am pretty weary of trying to fix this whole naming mess by introducing entirely new terms.
I think there is an extremely high risk that any attempt to do so will end up with an ecosystem that uses the current set of N terms plus any new ones that are introduced.
(xkcd: Standards)

Second, I think this discussion should pay a lot of attention to what mental models and concepts most users are likely to have internalised already.
(The first priority should be to “do no harm” and make sure any well intentioned action does not add to existing confusion.)

To me, the existing “Smart Proxy” term is the central and key term that needs to be clarified.
This term jumps out at users right at the top of the Foreman manual: Foreman :: Manual
It is also the term that is used in the UI (“Infrastructure > Smart Proxies”).

For better or for worse, “Smart Proxy” is the term users are likely to have built their mental models around.
Any attempt to change this term would be pretty disruptive and would have to be performed extremely rigorously to avoid doing more harm than good.
I believe this needed rigour is quite frankly impossible in the context of a large and sprawling open source ecosystem.

As a result, I am against any attempt to replace this term, or to restrict it to a narrow technical context/definition (however sub optimal it may be and irrespective of whether developers are currently using it in such a way).

Taking all of this into account, I arrive at something like the following:

• “Foreman Smart Proxy” is a high level concept, that refers to a set of Foreman (or Katello) features that may (but don’t necessarily) have to be installed on a separate host from the main Foreman server.
• In a narrow technical context “Smart Proxy” may also refer to a specific software component, but most users don’t care about that (trust me on this one).
• Wherever appropriate, it should be made clear, that Foreman installations generally (always?) come with a “Bundled Smart Proxy” (alternatively “Bundled Smart Proxy functionality” or “Bundled Smart Proxy features”) on the main Foreman server.
• There is a large overlap between this term (as I have defined/used it) and “Satelite Capsule Server” (though the latter is perhaps somewhat more narrowly defined).
  As a result, “Capsule” should not be used in any context ouside of Red Hat Satelite.
  It just breeds confusion by adding an entirely different term for something very similar but not exactly the same as “Smart Proxy”.
• Wherever possible all naming should use the full term “Smart Proxy” and never just “Proxy”.
  “Proxy” is a super ambiguous overloaded term.
  “Foreman Proxy” should almost always be “Foreman Smart Proxy”.
  This is also (and especially) true for variable names (smart_proxy, smart_proxy).
• This point also applies to other types of proxies, it is almost always better to explicitly speak of “HTTP proxies” (and not just “proxies”).
• Katello does not really add any additional complexity.
  A Foreman + Katello installation simply has “Smart Proxies” (either bundled with the main installation or on separate hosts) that have various Katello features in their feature set.

The alternative would be a one time rigorous (and disruptive) renaming, that would need to start with the term used in the UI and existing docs first and foremost.

Disclaimer: Obviously this is all a matter of opinion and everyone should feel free to criticize it both on the details and the general approach. I am opinionated here, but certainly not beyond persuasion.

PS: One final explicitly nonconstructive contribution: The natural term for a “Foreman Smart Proxy” installation on a separate host (as opposed to the “bundled” one on the main Foreman Server), is of course a “Foreman Smart Proxy Satellite installation”.
Since the term “Satellite” is not yet in use within Foreman, this will not be confusing at all!

[lzap]

@quba42

I think there is an extremely high risk that any attempt to do so will end up with an ecosystem that uses the current set of N terms plus any new ones that are introduced.

The more I think about this, the more I lean towards avoiding introducing a new term and streamlining what we have in some reasonable way.

[ehelms]

@quba42

Having written a lot of (orcharhino) documentation I have struggled with the Smart Proxy, Capsule, etc. nomenclature and feel I need to add my two cents.

I highly appreciate your two cents in this particular RFC piggybank.

@quba42

Second, I think this discussion should pay a lot of attention to what mental models and concepts most users are likely to have internalised already.

This is an important point, and one I have found hard to gather information on. Community participation in these RFCs helps a lot.

@quba42

Any attempt to change this term would be pretty disruptive and would have to be performed extremely rigorously to avoid doing more harm than good.

This would, and it can take time. But it’s do-able if beneficial in the long run.

I do think that at times the stigma of the word “proxy” gets developers hung up as the smart-proxy today is used for “smart” proxying in some cases and more of a service discovery tool in others.

@quba42

“Foreman Proxy” should almost always be “Foreman Smart Proxy”.

Do I read this recommendation correctly that the concept should be Foreman Smart Proxy while the software should remain as smart-proxy?

I get a sense from discussions that at a minimum, we could make a change to drop the ‘foreman-proxy’ packaging and nomenclature to embrace smart-proxy. Allowing continued conversation about smart-proxy getting a rename or a conceptual term in addition. But this would at least eliminate the thin layer of unnecessary abstraction that is foreman-proxy vs smart-proxy.

[quba42]

@ehelms

Do I read this recommendation correctly that the concept should be Foreman Smart Proxy while the software should remain as smart-proxy?

I was mainly trying to take aim at the term “Foreman Proxy” (in high level English language usage) as being unhelpful/confusing/ambiguous. The reasons are that:

1. The term “Proxy” is so vague on its own. (It is used for all kinds of things within the context of foreman).
2. People are already used to thinking about “Smart Proxies” from the UI and the Foreman manual, so leaving out the “Smart” just begs the question if “Foreman Proxy” is the same thing, a related thing, or a completely different thing.

I am not entirely sure what consequences this has for the best possible packaging and software naming scheme because I am not sure whether I have fully understood the status quo here. You state at the top that “foreman-proxy” is the naming scheme used by “RPM and Debian packaging and deployment”. While “smart-proxy” is a specific software with plugins. Does that mean the “smart-proxy” software is being packaged in packages named “foreman-proxy”, or is it a different (overlapping?) set of software that is being packaged in these packages?

[ekohl]

The Smart Proxy is a proxy for various features, such as DNS, DHCP and others. The smart part means it has some service discovery. All this makes them consumable for Foerman. I still think Smart Proxy is a correct name.

The problem is that Katello really breaks this. Pulp is not proxied but rather accessed directly. It does use the “smart” part which is service discovery. That’s why the name might feel bad.

If you’ve never had to deal with the content aspect, it makes sense and is quite close to a reverse proxy.

So generally I see 2 solutions here. One is what’s presented and that’s to move to the Katello model of viewing things. The other is to move Katello closer to the Foreman model.

IMHO content is not special enough to deserve renaming everything.

[lzap]

@ekohl

The problem is that Katello really breaks this. Pulp is not proxied but rather accessed directly. It does use the “smart” part which is service discovery. That’s why the name might feel bad.

I actually see providing the content instead of proxing as part of the “smart” word too

[ekohl]

@lzap

I actually see providing the content instead of proxing as part of the “smart” word too

I don’t, just as I don’t see providing Puppet catalogs to Puppet clients part of the smart proxy. Talking DHCP to DHCP clients isn’t either nor is talking DNS. The goal is to provide a control plane over these services so they provide the correct responses to clients.

[quba42]

@ekohl

The problem is that Katello really breaks this. Pulp is not proxied but rather accessed directly. It does use the “smart” part which is service discovery. That’s why the name might feel bad.

Ideally one wants terminology that works well on all levels, but I really don’t think users care about such distinctions very much. Putting on my user hat, it is called “Proxy” because it is sometimes on a separate host, and it is called “Smart” because people like calling stuff smart. It has a bunch of complicated stuff on it that I don’t particularly care about (so long as it works), and the only difference it makes if I am using Katello is that it has even more complicated stuff on it.