-
Notifications
You must be signed in to change notification settings - Fork 516
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
Add modeled types for URLs and Kubernetes resources #549
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm still a little bit nervous about being too strict about some of these types, but given the specs you found I feel good about the decisions that were made here.
Just a few comments.
@@ -282,3 +303,401 @@ mod test_valid_identifier { | |||
assert!(Identifier::try_from("💝").is_err()); | |||
} | |||
} | |||
|
|||
// =^..^= =^..^= =^..^= =^..^= =^..^= =^..^= =^..^= =^..^= =^..^= |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
😸
// It's very common to specify URLs without a scheme, so we add one and see if that | ||
// fixes parsing. | ||
let prefixed = format!("http://{}", input); | ||
if let Ok(_) = prefixed.parse::<url::Url>() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like this approach!
This improves errors when API requests are formatted or specified incorrectly, for example mixing up fields in user data.
This push just clarifies error messages for unit tests that fail, making the Url tests consistent with others. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🍹
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🦃
|
||
#[snafu(display("{} must match '{}', given: {}", thing, pattern, input))] | ||
Pattern { | ||
thing: String, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
small nit: Could there be a better way to represent this field? Maybe modeled-type
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's not exactly that, it's a descriptive string regarding the... thing... the error might be about. It's a bit more general than modeled type. Perhaps desc
?
This improves errors when API requests are formatted or specified incorrectly,
for example mixing up fields in user data.
Depends on #546.
Testing done:
All of the updated fields now give clear(er) errors if given invalid values.
invalid cluster name:
invalid label key:
invalid label value:
invalid taint value:
invalid target base url:
invalid metadata base url:
invalid ntp server:
invalid host container source:
invalid api server:
Here I screwed up a boolean:
You'll note that some of the errors look the same and don't specify the exact setting that was invalid. I don't think people are likely to specify the same invalid value multiple times and be confused, but I recognize that it could be improved and would like to in the future. Same point for potentially over-verbose errors.
With all of the modified fields specified with "normal" values, everything was happy and the instance joined my cluster. I checked the config files populated by these values and they looked right.
Also, because I haven't tested this before, I made sure to test a node taint; I was able to see the taint, and then run a pod on it, but only if I specified a toleration.