Integrating requestctl-generated haproxy dsl in our configuration isn't as simple as slapping the relevant code in a file, and include it from tls.cfg. In fact, haproxy doesn't have the concept of includes at all, but it can load multiple files.
I think we basically have two options:
- We rewrite the haproxy config as a confd::file, where we inject the requestctl rules in the right place
- We create an "admission backend" to haproxy, defined in a separated file and with all the requestctl ACLs, to which we rely the request, and which will take care of relying the request back to varnish.
I see pros and cons to both approaches, namely:
- Single file: it makes the file more unreadable and slightly harder to maintain, and the template harder to reason about in general. On the other hand, nothing would change of our production setup, more or less. So while this solution is uglier, it has less unknowns.
- Separate backend: of course it's more readable and easier to manage, and could even allow us to do fancier things over time, but at the cost of a significant change in how we serve things at the TLS layer and the risk of some issues arising from adding another http proxy.
I think ultimately this is the Traffic's team choice.
