Skip to content

split out synthetic policies for readability#2310

Merged
hawkw merged 8 commits intoeliza/policy-discoveryfrom
ver/eliza/policy-discovery/0
Mar 11, 2023
Merged

split out synthetic policies for readability#2310
hawkw merged 8 commits intoeliza/policy-discoveryfrom
ver/eliza/policy-discovery/0

Conversation

@olix0r
Copy link
Member

@olix0r olix0r commented Mar 11, 2023

No description provided.

@olix0r olix0r requested a review from a team as a code owner March 11, 2023 03:11
@olix0r olix0r force-pushed the ver/eliza/policy-discovery/0 branch from 882717c to 2cc158d Compare March 11, 2023 03:11
@olix0r olix0r force-pushed the ver/eliza/policy-discovery/0 branch from 2cc158d to d77445b Compare March 11, 2023 03:19
Comment on lines -107 to -112
} else if let Some(profiles::LogicalAddr(ref addr)) = profile.addr {
policy::BackendDispatcher::BalanceP2c(
ewma,
policy::EndpointDiscovery::DestinationGet {
path: addr.to_string(),
},
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 case isn't meaningful because we expect the policy control to always return for anything we could balance over.

Copy link
Member Author

Choose a reason for hiding this comment

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

It turns out this was load-bearing for integration tests: when profiles provided a logical name, we would proceed with balancing/discovery on that name. But this isn't how we expect things to work in practice: We want to rely on the policy controller to provide service information. If it doesn't know about a service, we expect to fallback to a forward stack.

rx
}

fn synthesize_forward_policy(
Copy link
Member Author

Choose a reason for hiding this comment

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

I moved this out of client-policy because it's basically a hardcoded configuration. I wouldn't want to rely on it anywhere else but here.

Copy link
Contributor

@hawkw hawkw left a comment

Choose a reason for hiding this comment

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

this looks great, thanks for taking the time to fix up the tests (i didn't want to do that). i had some very minor nits to pick but i can address some of them myself after merging, as well.

}

fn synthesize_forward_policy(
name: impl ToString,
Copy link
Contributor

Choose a reason for hiding this comment

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

nit, TIOLI: i feel like this could maybe take an Arc<Meta> rather than an impl ToString --- we use hard-coded strings ("endpoint" and "fallback") for the name, so that could be a singleton rather than creating a new Arc<Meta> for every synthesized policy? not a blocker.

Copy link
Member Author

Choose a reason for hiding this comment

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

keep in mind this is going to happen at most once per connection (and less frequently than that in practice).

Comment on lines +127 to +129
e.downcast_ref::<tonic::Status>()
.map(|s| s.code() == tonic::Code::NotFound)
.unwrap_or(false)
Copy link
Contributor

Choose a reason for hiding this comment

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

currently the error is always a Status at the top level, but it occurs to me that this is a bit brittle in that the error might get wrapped...maybe this should traverse a whole source chain if there is one? we can address separately though.

Copy link
Member Author

Choose a reason for hiding this comment

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

oh yeah we should use the errors helper here probably but it's fine for now.

tracing::debug!(?policy, profile = ?*profile.borrow(), "Synthesizing policy from profile");
let (tx, rx) = watch::channel(policy);
tokio::spawn(async move {
let mut profile = profile;
Copy link
Contributor

Choose a reason for hiding this comment

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

is this necessary? profile is already mut in the function declaration...

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 was probably here first. can be removed.

return;
}
}
});
Copy link
Contributor

Choose a reason for hiding this comment

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

occurred to me that this future maybe ought to have a span indicating the orig_dst or something, since otherwise, the logs here are not going to tell us which policy watch any of this happened to...i can address that after merging though.

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 already know it on the parent span

Copy link
Member Author

Choose a reason for hiding this comment

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

oh but we do want in_current_span here

@hawkw hawkw merged commit cdfe49d into eliza/policy-discovery Mar 11, 2023
@hawkw hawkw deleted the ver/eliza/policy-discovery/0 branch March 11, 2023 18:11
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