Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Show RoutingGroup info in query history #607

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

andythsu
Copy link
Member

@andythsu andythsu commented Feb 3, 2025

Description

It is useful to show what routing group a request is being routed to because if two routing groups have the same routedTo url, it will show the wrong information on the history page

Old:
image

New:
image

Additional context and related issues

Release notes

( ) This is not user-visible or is docs only, and no release notes are required.
(X) Release notes are required. Please propose a release note for me.
( ) Release notes are required, with the following suggested text:

@cla-bot cla-bot bot added the cla-signed label Feb 3, 2025
@andythsu andythsu force-pushed the routing_group branch 4 times, most recently from f57f2ad to d23d058 Compare February 3, 2025 11:48
@ebyhr ebyhr removed their request for review February 5, 2025 23:24
{
Optional<String> previousBackend = getPreviousBackend(request);
String clusterHost = previousBackend.orElseGet(() -> getBackendFromRoutingGroup(request));
// This falls back on adhoc routing group if no routing group can be determined
String routingGroup = routingGroupSelector.findRoutingGroup(request).orElse("adhoc");
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

moving this call out of the orElseGet will cause the routing logic to be triggered for every incoming request, including those containing query IDs. Please revert

*/
package io.trino.gateway.ha.handler;

public record RoutingDestinationInfo(String group, String clusterUri) {}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It would expand the scope of this change, but it seems like a good time to add some audibility on which rules were triggered. For example, you could have RoutingDestinationInfo(String group, String clusterUri, List<String> rulesFired), where rulesFired would contain the names of all rules who's condition evaluated to true. We can chat about this offline

Copy link
Member Author

@andythsu andythsu Feb 27, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should this be a simple String instead of List<String since only the first matching rule gets triggered?

*/
package io.trino.gateway.ha.handler;

public record RoutingDestinationInfo(String group, String clusterUri) {}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can clusterUri be URIinstead of aString`?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yep

@@ -85,11 +85,11 @@ void testByRoutingGroupHeader()
// If the header is present the routing group is the value of that header.
when(mockRequest.getHeader(ROUTING_GROUP_HEADER)).thenReturn("batch_backend");
assertThat(RoutingGroupSelector.byRoutingGroupHeader().findRoutingGroup(mockRequest))
.isEqualTo("batch_backend");
.contains("batch_backend");
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why do we need to change this?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

changing this because findRoutingGroup returns an Optional<String> now

String clusterHost = previousBackend.orElseGet(() -> getBackendFromRoutingGroup(request));
// This falls back on adhoc routing group if no routing group can be determined
String routingGroup = routingGroupSelector.findRoutingGroup(request).orElse("adhoc");
String user = request.getHeader(USER_HEADER);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This may not be always true, especially in case of bearer tokens (JWT). But I see that this logic is from before and it's not newly added as a part of the PR.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can take care of this in a different PR

@mosabua
Copy link
Member

mosabua commented Feb 26, 2025

Let us know when you need another review cycle @andythsu

@andythsu andythsu force-pushed the routing_group branch 4 times, most recently from cb61497 to 8d6609b Compare February 28, 2025 04:43
Optional<String> previousCluster = getPreviousCluster(queryId, request);
RoutingDestination routingDestination = previousCluster.map(cluster -> {
String routingGroup = queryId.map(routingManager::findRoutingGroupForQueryId)
.orElse("adhoc");
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@willmostly in the case where previousCluster is found but queryId is not found (i.e., cookie-based routing), how should we handle the value for routing group?

Copy link
Member

@Chaho12 Chaho12 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM 👍

@Chaho12
Copy link
Member

Chaho12 commented Mar 5, 2025

@andythsu

It is useful to show what routing group a request is being routed to because if two routing groups have the same routedTo url, it will show the wrong information on the history page

I notice that if two routing groups have same proxyTo url, then history page shows wrong routedTo(Name) too. Have you seen this happen?

@andythsu
Copy link
Member Author

andythsu commented Mar 5, 2025

@andythsu

It is useful to show what routing group a request is being routed to because if two routing groups have the same routedTo url, it will show the wrong information on the history page

I notice that if two routing groups have same proxyTo url, then history page shows wrong routedTo(Name) too. Have you seen this happen?

@Chaho12 yes I'm aware of this. The reason is because we don't store name in the query_history table, and when we pull history in here it maintains a mapping from proxyTo to name, essentially overwriting previous name with a new name.

@andythsu
Copy link
Member Author

andythsu commented Mar 5, 2025

Also I think we should probably change the language here to match the column names in db to make things consistent... Or at least call it a different name because it's weird to have two RoutedTo

@Chaho12
Copy link
Member

Chaho12 commented Mar 5, 2025

Also I think we should probably change the language here to match the column names in db to make things consistent... Or at least call it a different name because it's weird to have two RoutedTo

I agree.. was thinking simply like Name. I'll send a pr on changing name, as this is different issue.

Btw while I was looking code I notice that not only Name but also the issue is with the data that gets overwritten when proxyTo is not unique.

Copy link

cla-bot bot commented Mar 14, 2025

Thank you for your pull request and welcome to our community. We could not parse the GitHub identity of the following contributors: asu80.
This is most likely caused by a git client misconfiguration; please make sure to:

  1. check if your git client is configured with an email to sign commits git config --list | grep email
  2. If not, set it up using git config --global user.email [email protected]
  3. Make sure that the git commit email is configured in your GitHub account settings, see https://github.com/settings/emails

@cla-bot cla-bot bot removed the cla-signed label Mar 14, 2025
@cla-bot cla-bot bot added the cla-signed label Mar 14, 2025
Copy link
Member

@vishalya vishalya left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

Successfully merging this pull request may close these issues.

5 participants