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 FullyQualifiedAuthority::normalize to always return authority #476

Merged
merged 3 commits into from
Feb 28, 2018

Conversation

hawkw
Copy link
Contributor

@hawkw hawkw commented Feb 27, 2018

As requested by @briansmith in #415 (comment) and #415 (comment), I've refactored FullyQualifiedAuthority::normalize to always return a FullyQualifiedAuthority, along with a boolean value indicating whether or not the Destination service should be used for that authority.

This is in contrast to returning an Option<FullyQualifiedAuthority> where None indicated that the Destination service should not be used, which is what this function did previously.

This is required for further progress on #415.

Copy link
Contributor

@briansmith briansmith left a comment

Choose a reason for hiding this comment

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

Nice! Thanks for doing this. I just have a couple of nits.

@@ -5,9 +5,26 @@ use std::str::FromStr;

use http::uri::Authority;

/// A fully qualified authority according to Kubernetes service naming
/// conventions.
Copy link
Contributor

Choose a reason for hiding this comment

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

Actually, this isn't restricted to things that are named according to Kuberentes conventions. I suggest something like "A normalized Authority."

#[derive(Clone, Debug, Eq, Hash, PartialEq)]
pub struct FullyQualifiedAuthority(Authority);

/// A fully qualified authority, and whether or not the `Destination` service
/// should be queried for that name.
Copy link
Contributor

Choose a reason for hiding this comment

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

This comment just repeats exactly what the code says, so I don't think we should include it, so that we don't have to keep it in sync with code changes in the future.

impl NamedAddress {
#[inline]
pub fn without_trailing_dot(&self) -> &Authority {
self.name.without_trailing_dot()
Copy link
Contributor

Choose a reason for hiding this comment

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

let's just drop this and have callers use self.name.without_trailing_dot() directly. In general we should avoid these forwarding methods unless they save a non-trivial effort on the caller side.

@hawkw hawkw dismissed briansmith’s stale review February 27, 2018 23:04

All requested changes made in 86a641a

Copy link
Contributor

@seanmonstar seanmonstar left a comment

Choose a reason for hiding this comment

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

💯

@hawkw
Copy link
Contributor Author

hawkw commented Feb 28, 2018

I'm not sure why this PR's CI build has been in the "Waiting for status to be reported" state for over an hour --- I suspect Travis is misbehaving?

@hawkw
Copy link
Contributor Author

hawkw commented Feb 28, 2018

The travis web UI claims that this branch built successfully, so I think GitHub just failed to receive the success notification or something.

I can't merge this branch without a CI success, but maybe @olix0r or someone else with admin access can?

@briansmith
Copy link
Contributor

The travis web UI claims that this branch built successfully, so I think GitHub just failed to receive the success notification or something.

I can't merge this branch without a CI success, but maybe @olix0r or someone else with admin access can?

I've had the same issue before:

git commit -s -m "kick CI." --allow-empty && git push

(There are probably typos there, but you get the idea.)

Signed-off-by: Eliza Weisman <eliza@buoyant.io>
@hawkw
Copy link
Contributor Author

hawkw commented Feb 28, 2018

Thanks Brian, hopefully it will behave this time...

@hawkw
Copy link
Contributor Author

hawkw commented Feb 28, 2018

I restarted the most recent build of this branch, as the failure was on the web build job. Since there were no web changes, I suspect the failure was spurious.

@hawkw hawkw merged commit 41bef41 into master Feb 28, 2018
@hawkw hawkw removed the review/ready Issue has a reviewable PR label Feb 28, 2018
hawkw added a commit that referenced this pull request Mar 1, 2018
#476)

As requested by @briansmith in #415 (comment) and #415 (comment), I've refactored `FullyQualifiedAuthority::normalize` to _always_ return a `FullyQualifiedAuthority`, along with a boolean value indicating whether or not the Destination service should be used for that authority. 

This is in contrast to returning an `Option<FullyQualifiedAuthority>` where `None` indicated that the Destination service should not be used, which is what this function did previously.

This is required for further progress on #415.

Signed-off-by: Eliza Weisman <eliza@buoyant.io>
@olix0r olix0r deleted the eliza/normalize-refactor branch April 30, 2018 23:20
khappucino pushed a commit to Nordstrom/linkerd2 that referenced this pull request Mar 5, 2019
linkerd#476)

As requested by @briansmith in linkerd#415 (comment) and linkerd#415 (comment), I've refactored `FullyQualifiedAuthority::normalize` to _always_ return a `FullyQualifiedAuthority`, along with a boolean value indicating whether or not the Destination service should be used for that authority. 

This is in contrast to returning an `Option<FullyQualifiedAuthority>` where `None` indicated that the Destination service should not be used, which is what this function did previously.

This is required for further progress on linkerd#415.

Signed-off-by: Eliza Weisman <eliza@buoyant.io>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants