-
-
Notifications
You must be signed in to change notification settings - Fork 328
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
Pod logs operation #50
Conversation
add pod log operation support
Oh, this is really good! Thanks a lot for doing this. Looks like you ran into quite a few special cases. Will try to review this one a bit, as there are a few things I'm a bit unsure about, but overall it looks good. |
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.
This is very nice. Have left a suggestion that I think would make it slightly nicer. Lemme know what you think.
examples/log_openapi.rs
Outdated
let config = config::load_kube_config().expect("failed to load kubeconfig"); | ||
let client = APIClient::new(config); | ||
|
||
let mypod: &str = "mypod"; |
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.
can we get this from arg1?
@@ -58,6 +59,8 @@ impl Api<Object<PodSpec, PodStatus>> { | |||
} | |||
} | |||
|
|||
impl Log for Api<Object<PodSpec, PodStatus>> {} |
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.
Rather than having a one line impl for one resource object that every user would need to import the trait of, could we instead:
- have
log
always public butunimplemented!()
or{}
by default - have an extra
impl Api<Object<PodSpec, PodStatus>>
that overrideslog
Then you have one less import required for users.
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 implements log operation in this way, because I hope trait Log
can be reused by other developers when they implement their crds.
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.
Yeah, that makes sense. Either way is fine, it would just be easier for users of the Api to not have to import the extra trait.
fn log(&self, name: &str, lp: &LogParams) -> Result<String> { | ||
Ok(self.log_operation(name, lp)?) | ||
} | ||
} |
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.
This is a nice setup between private and public methods that looks like it allows you to very easily implement the Log trait. Cool pattern. Unfortunately, if you follow do my suggestion, this won't be needed.
I'll merge this as it stands, my other point is not important. Thanks again! |
using traits to implements log operation in #30