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

Fix bug in service-resolver redirects if the destination uses a default resolver. #6122

Merged
merged 5 commits into from
Jul 12, 2019

Conversation

rboyer
Copy link
Member

@rboyer rboyer commented Jul 12, 2019

Also:

  • add back an internal http endpoint to dump a compiled discovery chain for debugging purposes

Before the CompiledDiscoveryChain.IsDefault() method would test:

  • is this chain just one resolver step?
  • is that resolver step just the default?

But what I forgot to test:

  • is that resolver step for the same service that the chain represents?

This last point is important because if you configured just one config
entry:

kind = "service-resolver"
name = "web"
redirect {
  service = "other"
}

and requested the chain for "web" you'd get back a default resolver
for "other". In the xDS code the IsDefault() method is used to
determine if this chain is "empty". If it is then we use the
pre-discovery-chain logic that just uses data embedded in the Upstream
object (and still lets the escape hatches function).

In the example above that means certain parts of the xDS code were going
to try referencing a cluster named "web..." despite the other parts of
the xDS code maintaining clusters named "other...".

…lt resolver.

Also:
- add back an internal http endpoint to dump a compiled discovery chain for debugging purposes

Before the CompiledDiscoveryChain.IsDefault() method would test:

- is this chain just one resolver step?
- is that resolver step just the default?

But what I forgot to test:

- is that resolver step for the same service that the chain represents?

This last point is important because if you configured just one config
entry:

    kind = "service-resolver"
    name = "web"
    redirect {
      service = "other"
    }

and requested the chain for "web" you'd get back a **default** resolver
for "other".  In the xDS code the IsDefault() method is used to
determine if this chain is "empty". If it is then we use the
pre-discovery-chain logic that just uses data embedded in the Upstream
object (and still lets the escape hatches function).

In the example above that means certain parts of the xDS code were going
to try referencing a cluster named "web..." despite the other parts of
the xDS code maintaining clusters named "other...".
@rboyer rboyer added this to the 1.6.0-beta2 milestone Jul 12, 2019
@rboyer rboyer requested a review from a team July 12, 2019 16:26
@rboyer rboyer self-assigned this Jul 12, 2019
command:
- "server"
- "-http-port"
- ":8080"
- "-grpc-port"
- ":8079"
- "-redirect-port"
Copy link
Member Author

Choose a reason for hiding this comment

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

This wasn't used and it was only generating an error when it collided with other fortio instances.

Copy link
Member

@banks banks left a comment

Choose a reason for hiding this comment

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

👍 Nice!

@rboyer rboyer merged commit 9138a97 into release/1-6 Jul 12, 2019
@rboyer rboyer deleted the fix-chain-resolver-redirects branch July 12, 2019 17:21
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants