I'd like to propose adding the following symbols to the API, to make it possible for remap plugins to do next-hop parent selection:
enum TSHostStatus enum TSHostStatusReason enum TSParentResultType class TSNextHopSelectionStrategy struct TSParentResult const char *ParentResultStr bool TSHostnameIsSelf(const char* hostname) bool TSHostStatusGet(const char *hostname, TSHostStatus* status, unsigned int *reason) void TSHostStatusSet(const char *hostname, TSHostStatus status, const unsigned int down_time, const unsigned int reason) TSParentResult* TSHttpTxnParentResultGet(TSHttpTxn txnp) void TSHttpTxnParentResultSet(TSHttpTxn txnp, struct TSParentResult* result) TSReturnCode TSRemapInitStrategy(TSNextHopSelectionStrategy *&strategy, void *ih, char *errbuf, int errbuf_size) I have a PR to do this, as well as example plugins for ConsistentHash and RoundRobin parent selection: https://github.com/apache/trafficserver/pull/7023 Everything except the last function exposes existing things in core which are necessary for parent selection. The last function is how parent selection will actually be done: it exposes a concept already in core: registering a "strategy" for parent selection. The `TSRemapInitStrategy` is a pure virtual class (interface) which plugins will implement, to register a "strategy" (which is already a concept in core, and replaces traditional parent.config selection). The strategy has the functions findNextHop, markNextHop, nextHopExists, responseIsRetryable, onFailureMarkParentDown, goDirect, and parentIsProxy. Everything necessary to do parent selection. The interface is probably the most contentious part. Having dived into HttpSM.cc and HttpTransact.cc, I believe the ideal solution would be to have independent remap plugin functions for each of the interface functions above, share transaction data between them via Continuations, and share global data via a global plugin data mechanism like TSUserArgs or Extendible. The problem is, unless I'm greatly mistaken, doing so would require significantly refactoring the State Machine. I believe a State would be required for each of the above functions, and additionally many functions are called from multiple places, so tracking where to return from each new state would also be necessary. I would like to propose we get the above into core, presumably for 10.0, and then as we have the time and risk tolerance, we can change the State Machine to be able to make the above independent functions, ideally before 10.0 is released so TSRemapInitStrategy never sees a release. But so we at least have the ability to make parent selection plugins, and we can incrementally improve it. I'm a newcomer to ATS dev, I want to be clear, I'm completely open to suggestions, however the community wants to decide. I don't want to push a design on anyone. I would like to push for some form of parent selection plugins. It's a very valuable feature for Comcast, and I'd expect for other people as well. The above proposal is just what I perceived as the ideal middle ground between getting the feature in, risk tolerance, refactoring the world, and the ideal plugin format. I'm more than willing to adapt the PR for whatever the consensus is. Thanks,
