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

refactor: add AndFilter and break down existing filters #64

Merged
merged 7 commits into from
Sep 26, 2022

Conversation

IvanVergiliev
Copy link
Contributor

Description

This PR introduces an AndFilter that combines multiple NodeFilters and only passes if all sub-filters pass. This makes it very easy to add new filters and mix-and-match existing filters. The specific reason I'm adding this is to that I can add height-based or request-based filters in a follow-up PR and combine those with the existing ones.

Some high-level notes:

  1. I changed the HealthCheckManager test to better reflect its current responsibilities. Since the actual "IsHealthy" checks are not split across the various NodeFilters, the main job of the HealthCheckManager is to initialize and regularly execute the checks.
  2. I changed the HealthCheckManager to use a time.Ticker for testability. I wanted to confirm that the RunCheck calls are executed as expected without waiting 5 seconds in the test, so I switched the time.Sleep call with an injected Ticker. That way, in the test, I can force RunCheck invocations by emitting an item on the Ticker channel.
  3. Configuring node filters - right now, the set of node filters to create is hardcoded. When we start having multiple combinations that make sense, my plan is to use the NodeFilterType enum and add a filters: section in the YAML config so people can choose which filters to use.
  4. node_filter.go is getting a bit long. The individual types and functions are pretty short still so it seems tolerable. We can break it up into multiple files or a package when it gets unwieldy.

Type of change

  • 🐛 Bug fix (non-breaking change which fixes an issue)
  • 😎 New feature (non-breaking change which adds functionality)
  • ⁉️ Breaking change (fix or feature that would cause existing functionality to not work as expected)
  • ⚒️ Refactor (no functional changes)
  • 📖 Documentation (updating or adding docs)

How Has This Been Tested?

Unit tests for AndFilter and updated test for the HealthCheckManager.

for i := range h.configs {
config := h.configs[i]
zap.L().Debug("Running healthchecks on upstream.", zap.String("upstreamID", config.ID))
for range h.healthCheckTicker.C {
Copy link
Member

Choose a reason for hiding this comment

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

Like the ticker!

return result
}

type IsHealthyFilter struct {
Copy link
Member

Choose a reason for hiding this comment

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

nit: do we need Filter in the name? The other structs don't have it.

Copy link
Member

Choose a reason for hiding this comment

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

Or maybe just HealthyFilter? I feel like this Is prefix might be a little verbose. Indeed it's the general naming convention for boolean methods but I feel like the intent is already communicated clearly without the Is prefix.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Went with IsHealthy for consistency with the others.

Base automatically changed from filtering-routing-strategy to main September 26, 2022 12:32
@IvanVergiliev IvanVergiliev merged commit 46f1d7d into main Sep 26, 2022
@IvanVergiliev IvanVergiliev deleted the composite-filters branch September 26, 2022 12:50
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