Hi.
On 10/06/2018 17:56, amotz wrote:
Baptiste wrote:
Hi,
what's the use case?
Is this API gateway kind of thing?
Baptiste
From my experience this is mostly needed for operations/management API.
Some examples:
getStaus (i.e get the status/health from all endpoint)
flashCache (make all endpoint flash their cache)
setConfig (you get the point ...)
more...
with regard to the fan-in question by Jonathan.
Maybe return 207 (multi-status) https://httpstatuses.com/207 ?
IMO, the most intuitive response would be a json array of all the endpoints
responses, but I'm open for suggestions.
Let's say you have a `option allendpoints /_fan-out`.
When you now call `curl -sS https://haproxy:8080/_fan-out/health` then
you will receive a json from *all active* endpoints (pods,
app-server,...) with the result of there `/health`, something like this?
That sounds interesting. Maybe it's possible with a
`external-check command <command>` or some lua code?
https://cbonte.github.io/haproxy-dconv/1.8/configuration.html#external-check%20%28Alphabetically%20sorted%20keywords%20reference%29
Thanks,
Amotz
Best regards
Aleks
z
בתאריך יום א׳, 10 ביוני 2018 ב-14:23 מאת Baptiste <[email protected]
>:
On Sun, Jun 10, 2018 at 12:36 PM, Jonathan Matthews <
[email protected]> wrote:
On 10 June 2018 at 08:44, amotz <[email protected]> wrote:
> I found myself needing the options to do "fantout" for a call. Meaning
> making 1 call to haproxy and have it pass that call to all of the
endpoint
> currently active.
> I don't mind implementing this myself and push to code review Is this a
> feature you would be interested in ?
Hey Amotz,
I'm merely an haproxy user (not a dev and nothing to do with the
project from a feature/code/merging point of view), but I'd be
interested in using this.
I feel like an important part of it would be how you'd handle the
merge of the different server responses. I.e. the fan-in part.
I can see various merge strategies which would be useful in different
situations.
e.g. "Reply with *this* backend's response but totally ignore this
other backend's response" could be useful for in a logging/audit
scenario.
"Merge the response bodies in this defined order" could be useful for
structured data/responses being assembled.
"Merge the response bodies in any order, so long as they gave an HTTP
response code in the range of X-Y" could be useful for unstructured or
self-contained data (e.g. a catalog API).
"Merge these N distinct JSON documents into one properly formed JSON
response" could be really handy, but would obviously move haproxy's
job up the stack somewhat, and might well be an anti-feature!
I could have used all the above strategies at various points in my career.
I think all but the first strategy might well be harder to implement,
as you'll have to cater for a situation where you've received a
response but the admin's configured merging strategy dictates that you
can't serve the response to the requestor yet. You'll have to find
somewhere to cache entire individual response bodies for an amount of
time. I don't have any insight into doing that - I can just see that
it might be ... interesting :-)
If Willy and the rest of the folks who'd have to support this in the
future feel like this feature is worth it, please take this as an
enthusiastic "yes please!" from a user!
Jonathan
