Refine Errors

[kazk]

This issue keeps track of tasks related to improving errors in kube.

Currently, kube::Error is a huge enum containing all the possible errors, and many error variants don't provide any additional context (e.g., SerdeError(#[from] serde_json::Error)). Users need to constantly ignore irrelevant error variants, and they don't know which are relevant.

The use of #[from] attribute, which derives impl From<T> for kube::Error, allows implicit conversion, so the source code doesn't help much, either. The code is slightly more concise with From, but the information is lost, allows us to be more sloppy, and not think about error cases as much as we should.

We'll start addressing this problem by removing From to force us to attach context, and gradually breaking down the error into smaller and more specific errors (proposed in #686).

Tasks

• Remove impl From<T> for kube::Error and require explicit error mapping (Start Refining Errors #686)
• Remove kube_core::Error and add more specific errors as needed (Start Refining Errors #686)
• Break kube::Error down to smaller, and more specific error types.
  • Split kube::error::ConfigError into kube::client::AuthError (only client auth errors), and kube::config::{InferConfigError, InClusterError, KubeconfigError} (Refine more errors #696)
  • Move kube::error::OAuthError to kube::client::auth::oauth::Error (Refine more errors #696)
  • Move errors from WebSocket upgrade to kube::client::UpgradeConnectionError (Refine more errors #696)
  • Split kube::client::AuthError by methods
  • Add better errors for TLS
    • native-tls (Refine errors for Native TLS #716)
    • rustls-tls (Update rustls to 0.20.1 #704)
    • openssl-tls (Add openssl-tls feature #700)
  • Move kube::error::DiscoveryError to kube::discovery::Error
  • Add kube::client::Error
  • Add kube::api::Error
• Add #[non_exhaustive]
• Consistent naming convention
• dependency: Replace snafu with thiserror in kube-runtime and examples (Start Refining Errors #686)
• interoperability: Change Display to follow API Guidelines C-GOOD-ERR: "The error message given by the Display representation of an error type should be lowercase without trailing punctuation, and typically concise."
• interoperability: Follow the guidelines for implementing Display::fmt and Error::source and remove source from Display when the ecosystem is ready. Originally discussed in Don't include sources in their errors' display() #515.

[lswith]

I'd really like for kube::api::Error to also tell me which path is being used in the request. The current printing of 404s is:

ApiError: \"404 page not found\\n\": Failed to parse error data (ErrorResponse { status: \"404 Not Found\", message: \"\\\"404 page not found\\\\n\\\"\", reason: \"Failed to parse error data\", code: 404 })"}

No idea which resource this is for.

[clux]

I'd really like for kube::api::Error to also tell me which path is being used in the request. The current printing of 404s is:

ApiError: \"404 page not found\\n\": Failed to parse error data (ErrorResponse { status: \"404 Not Found\", message: \"\\\"404 page not found\\\\n\\\"\", reason: \"Failed to parse error data\", code: 404 })"}

No idea which resource this is for.

I don't believe that is part of the response from the apiserver. We get a metav1.Status which we turn into an ErrorResponse or a response::Status.

The normal way to get this information is to enable tracing (as per examples) and see what is being logged. All request methods log a debug level item about the call. See https://kube.rs/troubleshooting/#request-inspection