Supporting HA Foreman Proxies

Development
1

As some of you are probably aware I’ve been trying to get HA Proxies support in Foreman for a number of months now, almost a year! The discussion seems to have stalled and I’m looking for some help to move it forward.

Use cases I’m trying to solve:

  • As a user, I want to scale Foreman Proxies for more capacity.
  • As a user, I want to add more nodes to protect against hardware/software failure or user error.

The above use cases also requires solving the following (as having a load balancer between Foreman Proxy and Clients requires Foreman & Clients to use a different Hostname to connect to the Foreman Proxy):

  • As a user, I want my client connecting to Foreman Proxy on a different interface or network than Foreman connects to it.

To recap the current situation… The current models looks like:

erd-1
erd-11239×3409 236 KB

Hosts or Hostgroups are assigned a Smart Proxy, then Foreman and plugins use that for various actions (Orchestration, Remote Execution, goferd, Ansible, ect…) also the hostname in the Smart Proxy URL is used for rendering templates.

This doesn’t allow a Host or Hostgroup to be assigned multiple Smart Proxies, which is required so Foreman can ensure both Smart Proxies have the same state (TFTP, DHCP configs, Pulp content, ect…). Obviously to create HA Smart Proxies all Smart Proxies in that cluster are required to have the same state/configs, so the client gets the same response regardless of which one it is being routed to via a Load Balancer.

The solution:

Well, the current proposed solution :wink:

erd-1
erd-11495×3442 260 KB

I’ve added a Hostname model, the idea is that now all Hosts and Hostgroups are assigned a Hostname, that Hostname is in turn assigned one or many Smart Proxies. This allows:

  • Current scenario where one Smart Proxy is assigned to one Hostname.
  • “Multihoming” support, where one Smart Proxy has multiple Hostnames, Hosts will then be assigned whichever Hostname that want to use.
  • Highly Available Smart Proxies, where a Host must connect to one of the Smart Proxies via a Load Balancer and those Smart Proxies must all have the same state. Host or Hostgroup would be assigned a Hostname and that Hostname would in turn be assigned to multiple Smart Proxies, allowing Foreman to do Orchestration and other actions on all the Smart Proxies a host could use.

The current PR also does:

  • Create a Hostname when a Smart proxy is created based on the URL
  • Provides migration to create Hostnames for users existing Smart Proxies

Current issues:

  • Critical path API changes, as Host or Hostgroups are no longer assigned a Smart Proxy but instead a Hostname.
  • The current PR doesn’t change Orchestration and other actions to happen on all Smart Proxies, but that can be done!

How do we feel about this change?
Do you have another suggestions or improvements?

@Marek_Hulan had another proposal that didn’t change existing APIs, though I believe it was a little less flexable and made creating a Smart Proxy cluster a little more complicated and unintuitive IMHO. @Marek_Hulan If you’re serious about that proposal please describe it below.

2

This is an interesting topic for the construction day to discuss but some initial remarks.

Could you elaborate the Hostname class? It has a hostname and a name which is ambiguous.

Another question I have is about the relation Feature <-> SmartProxy and Feature <-> Hostname <-> SmartProxy. Isn’t the former relation implicitly available already then?

Personally I think every feature should have the option for something how the service can be reached by clients. The hard part might be that this can be either a hostname or a URL. Some services don’t really have this (DHCP).

1 Like