-
-
Notifications
You must be signed in to change notification settings - Fork 325
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 support for CRD ConversionReview
types
#999
Conversation
Codecov Report
@@ Coverage Diff @@
## master #999 +/- ##
==========================================
- Coverage 72.20% 71.89% -0.31%
==========================================
Files 64 65 +1
Lines 4573 4637 +64
==========================================
+ Hits 3302 3334 +32
- Misses 1271 1303 +32
|
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.
minor comments on documentation and naming, but this part is starting to look good
/// Copied from the corresponding consructing [`ConversionReview`]. | ||
/// This field is not part of the Kubernetes API, it's consumed only by `kube`. | ||
#[serde(skip)] | ||
pub types: Option<TypeMeta>, |
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.
In admission we have this as a non-optional field for both Response and Request (with skip still), is there a reason to keep it optional?
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.
No strong reason. It simplifies manual creation of ConversionRequest
a little bit (i.e. it may be surprising for user to see non-optional field which is not set by apiserver).
Signed-off-by: Mikail Bagishov <[email protected]>
Signed-off-by: Mikail Bagishov <[email protected]>
Signed-off-by: Mikail Bagishov <[email protected]>
1233492
to
1c6e382
Compare
Signed-off-by: Mikail Bagishov <[email protected]>
1c6e382
to
edad3da
Compare
Signed-off-by: Mikail Bagishov <[email protected]>
7d62020
to
eaa34e4
Compare
Signed-off-by: Mikail Bagishov <[email protected]>
Signed-off-by: Mikail Bagishov <[email protected]>
Signed-off-by: Mikail Bagishov <[email protected]>
Signed-off-by: Mikail Bagishov <[email protected]>
a11f832
to
1b2cef4
Compare
Signed-off-by: Mikail Bagishov <[email protected]>
} | ||
|
||
/// Returns an unsuccessful `Status` | ||
pub fn failure(message: &str, reason: &str) -> Self { |
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.
maybe we should split this up into a failure
with message
as the only param and have a with_reason(reason)
function on mut self
(or other way around if reason is the most important one - don't remember right now)
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.
actually, these two are very linked, it is probably a mistake to let people do one and not the other. ignore this.
while i am a bit uncomfortable with the double &str argument (which can be swapped around accidentally), there are probably smarter stuff we can do down the line to convert an Error
into a Status
by taking advantage of the Display
and Debug
traits for the error to fill these in a less error prone way.
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 can think of
fn from_error<E: Display>(err: &E, reason: &str) -> Self;
which uses e.to_string() as message (I don't see a way to infer reason from error, especially given guidelines that it shoud be short and PascalCase).
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.
Users could possibly do it in their app, if they did a convention like that if the Display was always PascalCase, and then they can take the Debug as the reason, but users would have to stay on top of their errors if so. We couldn't enforce that though, so there isn't much we can do in kube directly. We can experiment in controller-rs with some strategic error use in the future perhaps.
Signed-off-by: Mikail Bagishov <[email protected]>
1778fbb
to
68748d7
Compare
Signed-off-by: Mikail Bagishov <[email protected]>
Only one tiny nit left on the admission code that was cleaned up, but am otherwise happy with merging this. Thanks for all the back and forth on this. |
4a9a76d
to
54f31f1
Compare
CI is red, but this looks like issue with k3d action |
Signed-off-by: Mikail Bagishov <[email protected]>
54f31f1
to
4d1a801
Compare
Yeah, had the same issue on the k8s-openapi bump PR, so probably not resolvable here without pinning k3d. I'll give it one last re-run as a check before merging. |
ConversionReview
types
Yeah, consistently k3d action failing. I'll fix that in master with some pinning if necessary. Going to deal with this anyway in #1008. Going to merge this. Thanks a lot for all the work on this! |
Signed-off-by: Mikail Bagishov [email protected]
Motivation
Part of #992.
Solution
Compared to version in the old PR, I renamed
low_level.rs -> types.rs
, renamed moduleconversion.rs -> mod/conversion.rs
to align with rest of the code base, and made submodule private.