error handling when kube returns an error struct missing

[clux]

One thing I noticed is that data returned from the kube api is assumed to be parseable into the struct you give it: https://github.com/ynqa/kubernetes-rust/blob/9c5f29f1f70d31042371db8ed6782486a41c8e3b/src/client/mod.rs#L37

however, we have no real information on what went wrong if kube returns an error struct. We simply get a json parsing failed (usually "unexpected EOF" via serde) because the string is attempted to be coerced into a different struct to the one that contains the error.

This happens if you query for information about your own custom resources and you've failed to add the necessary rbac rules for it, but i'm sure there are many other cases.

There's currently got a fork to help me deal with this issue in my account (and to get some debug back when it's failed for now). I might be looking to submit a pr back if I stumble across a good solution to it. In the mean time, just thought this ought to be raised.

At any rate, thanks for this crate! It's allowed me to write a kube app with rust with only minor tweaks!

[ynqa]

@clux Thanks for your issues.

Ah.. right. If it happens any error on request, it's possible not to deserialize correctly for some k8s objects, such as Pod... This error handling is so not good.

There's currently got a fork to help me deal with this issue in my account (and to get some debug back when it's failed for now).

Here? https://github.com/clux/kubernetes-rust/commit/2b0397fb958d7931cb828fd51ac6e075a72cbbd8 I also welcome to your PRs about your improvements :)

[clux]

Yeah, that change. I added https://github.com/clux/kubernetes-rust/commit/4e3589dd66149cc70c5f3adb42c14fffc52d84fc as well, which will try to deserialize the error.

It's not enough to just pass on reqwests error type like i do later on, because you will miss out on the important reason for why things failed. Like say on a 403, the reason often includes:

crdgroup.domain "apps" is forbidden: User "system:serviceaccount:apps:developer" cannot get crdgroups.domain in the namespace "apps"

[ynqa]

@clux Sorry for my responses delay, look good to me about your improvements!! Essentially it should tackle handling some errors on APIs (generated) side. I have to choose below:

• for handling requests/responses, and their errors more flexibly, managing k8s APIs on own codes
• for maintaining API definition easily, rely on the code generator