Some of us spoke about this at cfgcamp in Ghent, I want to summarize what was discussed and agreed for wider distribution and feedback.
Use cases we want to cover:
- Clustering Smart Proxies together from a clients prospective & putting a load balancer in front of them.
- Clients accessing a Smart Proxy on a different Interface/Hostname/Route than Foreman would contact the Smart Proxy on (this is actually a requirement of the above)
To support the first use-case some Smart Proxies features requires Foreman always does an action on all of the Smart Proxies in a cluster (i.e TFTP) and others requires Foreman does an action on one Smart Proxy, but try the next if that fails (i.e external DNS) and others could be done using both methods (i.e Content - explained at ).
I have put together a diagram explaining these 2 scenario’s, a dotted line means normally only one of the connections will happen (though if there is an error, Foreman will try the other) A solid line means a connection will always happen.
Where Features could use both modes we are initially only going to cover one of the scenario’s; In the long term we would like to provide for both cases, but for now this logic will be stored in code, we could store it in a model in future if we wanted to allow for both.
- Foreman needs to have a way of Grouping Smart Proxies together on a per Feature basis & holding the Hostname/Route to access the service.
- Hosts & Subnets are currently associated with Smart Proxies, this would need to change to the new SmartProxyGroup/Route object.
- A SmartProxyGroup/Route containing one Smart Proxy will be created when a Smart Proxy is registered based of its URL.
- We will migrate existing Smart Proxies, creating a Group/Route for each of them.
- Were users do not want to Group Smart Proxies together, they can use a Smart Proxy Group of one.
- For users want to use one Smart Proxy but want clients to access it via a different hostname/route (Multi-homing; second use case), then they can create an additional Group/Route containing one Smart Proxy but a different Hostname/Route than the URL.
 If a group of Smart Proxies share the same content storage (Pulp) you may want to only create a Sync task on one and have the other operate in a “read-only” mode using the same storage (think NFS share). Not really HA but does allow load-balancing for more capacity.
Where we need your help
- Any feedback/input or questions?
- I encourage you to first checkout the existing PR, as it implements some the above plan.
- What do we call this model we use to group Smart Proxies together?
- It needs to hold a Hostname/Route that the service is accessiable via from the client
- Has a n:m relation with Smart Proxies
- Users select this object on the Host form, i.e “Puppet Proxy” is now “Puppet Route”
- Users select this on the Subnet forms, i.e “DHCP Proxy” becomes “DHCP Route”
- Our current best idea is “Route”, maybe “Client Route”.