Generated API hides kubernetes REST API response result

[jimjaeger]

Describe the bug
If kubernetes request returns a non 2xx response the generated kubernetes api returns HttpError 'HTTP request failed' and hides
the response details, e.g. error details / causes.

It makes it impossible to identify the cause.

For example, the createNamespacedJob API tolerates non valid label values (https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/) and send the job object to the REST API. As result the REST API returns a [422 Unprocessable Content] status code and a response body that contains the cause of the error. The returning error class does not contain the reponse body.

Example Reference:
https://github.com/kubernetes-client/javascript/blob/master/src/gen/api/batchV1Api.ts#L16

Client Version
Latest

To Reproduce
Steps to reproduce the behavior:

1. Create a Job with invalid label values e.g. abc="abc/def"
2. use createNamespacedJob API
3. Get HttpError without cause information

Expected behavior
Option1: Validate the input including the labels.
It is may not be possible if the openapi spec it does not defines. Label Definition:
"Map of string keys and values that can be used to organize and categorize (scope and select) objects. May match selectors of replication controllers and services. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/labels"

Option2: Return a detailed error class including the information from the REST API body.

Example Error response:

{
  "kind": "Status",
  "apiVersion": "v1",
  "metadata": {},
  "status": "Failure",
  "message": "Job.batch \"abc\" is invalid: [metadata.labels: Invalid value: \"abc/\": a valid label must be an empty string or consist of alphanumeric characters, '-', '_' or '.', and must start and end with an alphanumeric character (e.g. 'MyValue',  or 'my_value',  or '12345', regex used for validation is '(([A-Za-z0-9][-A-Za-z0-9_.]*)?[A-Za-z0-9])?'), spec.template.labels: Invalid value: \"avc==\": a valid label must be an empty string or consist of alphanumeric characters, '-', '_' or '.', and must start and end with an alphanumeric character (e.g. 'MyValue',  or 'my_value',  or '12345', regex used for validation is '(([A-Za-z0-9][-A-Za-z0-9_.]*)?[A-Za-z0-9])?')]",
  "reason": "Invalid",
  "details": {
    "name": "abc",
    "group": "batch",
    "kind": "Job",
    "causes": [
      {
        "reason": "FieldValueInvalid",
        "message": "Invalid value: \"abc/def\": a valid label must be an empty string or consist of alphanumeric characters, '-', '_' or '.', and must start and end with an alphanumeric character (e.g. 'MyValue',  or 'my_value',  or '12345', regex used for validation is '(([A-Za-z0-9][-A-Za-z0-9_.]*)?[A-Za-z0-9])?')",
        "field": "metadata.labels"
      },
      {
        "reason": "FieldValueInvalid",
        "message": "Invalid value: \"abc==\": a valid label must be an empty string or consist of alphanumeric characters, '-', '_' or '.', and must start and end with an alphanumeric character (e.g. 'MyValue',  or 'my_value',  or '12345', regex used for validation is '(([A-Za-z0-9][-A-Za-z0-9_.]*)?[A-Za-z0-9])?')",
        "field": "spec.template.labels"
      }
    ]
  }
}

[brendandburns]

As you say, client side validation isn't possible because the open api specification for things like labels isn't well defined.

For the second option, the body of the response should be in the error object somewhere, I'm pretty certain you can look at that response and get the details that are returned from the server. The client is not in a position to add additional error messages, it can only reply with what the server provides.

[brendandburns]

If you have ideas for improving this, please feel free to send a PR. But note that most of the code for interacting with the API server is code generated, and it needs to be code generated because of the volume of APIs and API changes, so if you want to make changes in the generated code it needs to be in the upstream code generator.

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[jimjaeger]

/remove-lifecycle stale