search

kubernetes-client / c

Official C client library for Kubernetes
Apache License 2.0
146 stars 45 forks source link

BatchV1API_createNamespacedJob does not return the failing reason. #189

Closed shayan-eftekhari closed 6 months ago

shayan-eftekhari commented 1 year ago

Hi,

I'm using the BatchV1API_createNamespacedJob API to create a Job.

If for any reason the process fails (e.g. if a job with the same name already exists), the API still returns a v1_job_t* with a kind equal to "Status" instead of "Job" but there is no way to understand the reason.

I digged into its implementation and I found this:

https://github.com/kubernetes-client/c/blob/6a82bde3470171aa3e8965f9e3766bda5fa5b170/kubernetes/api/BatchV1API.c#L327

The BatchV1APIlocalVarJSON local variable holds the actual reason, so I'm wondering if there is a way to report it back.

This might be also true on other APIs but I have not examined them yet.

Would you please let me know if there is a way to access the failure reason through the API, or if there is not, do you have a plan to make it possible? I'm wondering if it is possible to extend v1_job_status_t struct to hold such information.

Thank you in advance.

ityuhui commented 1 year ago

Does the apiClient->response_code meet your requirement ?

FYI https://github.com/kubernetes-client/c/issues/31#issuecomment-704710140

shayan-eftekhari commented 1 year ago

Thank you for looking into this. In this case (already existing job) response_code is 409 which is HTTP conflict. However, the BatchV1APIlocalVarJSON is a json object which has the exact error "jobs.batch already exists".

I can imagine the API may fail for various reasons (e.g. lack of some required fields in body), so being able to access this error message for the caller is a big plus.

In the provided example, CoreV1API_deleteNamespacedPod returns a v1_status_t which apparently has a field named message. This is exactly what I'm looking for in v1_job_t.status (data type: v1_job_status_t).

ityuhui commented 1 year ago

What's the value of elementToReturn in your code ?

https://github.com/kubernetes-client/c/blob/6a82bde3470171aa3e8965f9e3766bda5fa5b170/kubernetes/api/BatchV1API.c#L328

shayan-eftekhari commented 1 year ago

elementToReturn = { api_version = "v1", kind = "Status", metadata = { // All fields are 0 or NULL }, spec = NULL, status = { // All fields are 0 or NULL } }

ityuhui commented 1 year ago

Can you try to debug the function v1_job_parseFromJSON and v1_job_status_parseFromJSON to check why the v1_job_status_t is NULL ?

# Build
mkdir build
cd build
# If you want to use `gdb` to debug the C client library, add `-DCMAKE_BUILD_TYPE=Debug` to the cmake command line, e.g.
cmake -DCMAKE_BUILD_TYPE=Debug -DCMAKE_INSTALL_PREFIX=/usr/local ..
make
shayan-eftekhari commented 1 year ago

Here is the content of BatchV1APIlocalVarJSON that is passed to the v1_job_parseFromJSON function:

{
    "apiVersion": "v1",
    "kind": "status",
    "metadata": null,
    "status": "Failure",
    "message": "jobs.batch \"hello-world\" already exists",
    "reason": "AlreadyExists",
    "code": 409,
    "details": {
        "name": "hello-world",
        "kind": "jobs",
        "group": "batch"
    }
}

Then, the v1_job_parseFromJSON funtion extracts the status part:

cJSON *status = cJSON_GetObjectItemCaseSensitive(v1_jobJSON, "status");

which is a JSON string, "Failure", without any child (type: 16) and the passes it to the v1_job_status_parseFromJSON function. This function is then repeatedly calls cJSON_GetObjectItemCaseSensitive function to extract fields including "active", "completedIndexes", "completionTime", etc. However, cJSON_GetObjectItemCaseSensitive expects its input to be JSON object with a child and since it doesn't find a child, it returns NULL for all of them.

ityuhui commented 1 year ago

I see. So if you want detailed error messages instead of error codes like 409, I think the only way is to use generic client https://github.com/kubernetes-client/c/issues/31#issuecomment-707207108 to send the request and parse the json by yourself.

FYI https://github.com/kubernetes-client/c/tree/master/examples/generic

k8s-triage-robot commented 8 months ago

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

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

You can:

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

/lifecycle stale

k8s-triage-robot commented 7 months ago

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

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

You can:

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

/lifecycle rotten

k8s-triage-robot commented 6 months ago

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

This bot triages issues according to the following rules:

You can:

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

/close not-planned

k8s-ci-robot commented 6 months ago

@k8s-triage-robot: Closing this issue, marking it as "Not Planned".

In response to [this](https://github.com/kubernetes-client/c/issues/189#issuecomment-2014143638): >The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. > >This bot triages 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: >- Reopen this issue with `/reopen` >- Mark this issue as fresh with `/remove-lifecycle rotten` >- Offer to help out with [Issue Triage][1] > >Please send feedback to sig-contributor-experience at [kubernetes/community](https://github.com/kubernetes/community). > >/close not-planned > >[1]: https://www.kubernetes.dev/docs/guide/issue-triage/ Instructions for interacting with me using PR comments are available [here](https://git.k8s.io/community/contributors/guide/pull-requests.md). If you have questions or suggestions related to my behavior, please file an issue against the [kubernetes/test-infra](https://github.com/kubernetes/test-infra/issues/new?title=Prow%20issue:) repository.