Trino Gateway Routing Framework (WIP) about trino-gateway HOT 2 OPEN

simplifies the extension of the routing function, facilitates testing and verification

This is needed, thank you!

The overall philosophy looks good to me. I like that the current architecture is a specialization of the more general architecture here, so that we can provide built in plugins to current users and avoid breaking changes.

The label concept is appealing, and should allow more sophisticated routing decisions. Have you considered taking a bit more inspiration from kubernetes and using taints? For example you could taint a cluster like taints: ['oneMinuteMaxExecution'], and a routing plugin could either decide that that select 1 can tolerate this, or the client could add a header like X-Trino-Gateway-Toleration: oneMinuteMaxExecution. Otoh, maybe labels are sufficiently powerful.

from trino-gateway.

How about a feature/requirement section that includes the following info.

Features

• Block routing to backend on failure expected queries.
  • e.g) A repetition of failing query due to syntax/authorization error could be blocked in order to prevent unncessary connections from trino server to hive metastore/HDFS ranger in our case.
  • I know trino relies on connector's authentication, but we noticed that IDE or superset etc. executes lots of queries at once and creates lots of connections, which is not welcome to our hive metastore.
  • Also, we are planning to run explain and get statistics, and if query fails due to syntax error, there is no need to pass failure expected query onto backend.

from trino-gateway.