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

Allow handling special verbs/resources #30

Closed
clux opened this issue May 27, 2019 · 3 comments
Closed

Allow handling special verbs/resources #30

clux opened this issue May 27, 2019 · 3 comments
Labels
good first issue Good for newcomers help wanted Not immediately prioritised, please help!

Comments

@clux
Copy link
Member

clux commented May 27, 2019

There's a couple of special resources that need to be handled in less generic ways. E.g. just on pods alone:

pods/attach
pods/portforward
pods/eviction
pods/exec
pods/log

and maybe some node specific stuff. Don't see drain + cordon in the openapi.
We could allow customising these, but maybe the list is short enough to just have it as a feature.

@clux
Copy link
Member Author

clux commented Jun 2, 2019

We can make a generic_action query (with a verb and noun param) on RawApi and make native object specific wrappers on them in Api.

We do have do do some basic native object mapping of types to enum names anyway, so may as well map generic actions to those types.

At least, this is the cleanest way of doing it, I've thought of so far. Happy to take PRs for it. Don't have an immediate need for it myself yet.

@clux clux added good first issue Good for newcomers help wanted Not immediately prioritised, please help! labels Jun 2, 2019
@clux
Copy link
Member Author

clux commented Feb 9, 2020

We have a decent pattern for this that doesn't require massive amounts of generics:

  1. Implement subresource queries straight on RawApi without restrictions (for now):
impl RawApi {
    /// Get a pod logs
    pub fn log(&self, name: &str, lp: &LogParams) -> Result<http::Request<Vec<u8>>> {
        ...
    }
}
  1. Make a marker trait for the subresource:
pub trait LoggingObject {}

impl<K> Api<K>
where
    K: Clone + DeserializeOwned + KubeObject + LoggingObject,
{
    pub async fn log(&self, name: &str, lp: &LogParams) -> Result<String> {
        let req = self.api.log(name, lp)?;
        Ok(self.client.request_text(req).await?)
    }

    pub async fn log_stream(&self, name: &str, lp: &LogParams) -> Result<impl Stream<Item = Result<Bytes>>> {
        let req = self.api.log(name, lp)?;
        Ok(self.client.request_text_stream(req).await?)
    }
}
  1. Designate what resources implement this subresource:
impl LoggingObject for Object<PodSpec, PodStatus> {}
impl LoggingObject for Object<PodSpec, Void> {}

That ought to be it. Write one test case in examples (e.g. examples/log_openapi.rs).

Ought to be simple PRs for people who need extra functionality for subresources!

@clux clux changed the title Allow handling special verbs/resources Implement common subresources for special types Feb 9, 2020
@clux clux changed the title Implement common subresources for special types Allow handling special verbs/resources Feb 9, 2020
@clux
Copy link
Member Author

clux commented Feb 9, 2020

Opened #127 to replace this.

@clux clux closed this as completed Feb 9, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
good first issue Good for newcomers help wanted Not immediately prioritised, please help!
Projects
None yet
Development

No branches or pull requests

1 participant