CoreV1API_readNamespacedPodLog doesn't work and contains a segfault

[homer6]

The text/plain header is being rejected:

{\n  \"kind\": \"Status\",\n  \"apiVersion\": \"v1\",\n  \"metadata\": {},\n  \"status\": \"Failure\",\n  \"message\": \"only the following media types are accepted: application/json, application/yaml, application/vnd.kubernetes.protobuf\",\n  \"reason\": \"NotAcceptable\",\n  \"code\": 406\n}

Commenting out that header makes it work again. However, when it proceeds it'll segfault on the strdup line if there aren't any pod logs (null pointer).

I moved the strdup into the null pointer guard and it works now for pods both with and without logs.

    char* elementToReturn = NULL;

    if (apiClient->dataReceived) {
        elementToReturn = strdup((char*)apiClient->dataReceived);
        free(apiClient->dataReceived);
        apiClient->dataReceived = NULL;
        apiClient->dataReceivedLen = 0;
    }
    list_freeList(localVarQueryParameters);

[brendandburns]

read pod logs is a non-restful compliant API, I suspect that we will need to write custom code to correctly handle it.

[homer6]

It works after the code change. I'll submit a PR.

I'm writing a c++ client that wraps this library: https://github.com/homer6/kubepp

[brendandburns]

Unfortunately, that code is generated. If we want to make changes, we need to change the upstream generator (and validate that it doesn't break other API calls)

cc @ityuhui

[brendandburns]

Also, for your C++ client, I would also recommend you take a code generation approach, since it is basically impossible to keep up with the breadth of the Kubernetes API without code generation.

[homer6]

That makes sense. However, I'm finding that a number of function calls are not working as expected. By implementing each call individually, I'm able to validate that the calls are working as expected.

So far, I've only implemented a handful of methods and most of them have failed in different ways.

Sorry for the poor feedback. I'm actually really excited to keep going with wrapping this library.

[ityuhui]

As @brendandburns said, the code in this library is generated by openapi-generator/libcurl https://github.com/OpenAPITools/openapi-generator/tree/master/modules/openapi-generator/src/main/resources/C-libcurl

Code changes you commit to this repository will be removed on the next generating.

Feel free to submit your PR here and we can review the code changes and suggest changes to openapi-generator/libcurl.

Don't wait for all changes to be done to submit your PR as your PR is just for review. Only 1 or 2 changes are OK.

[homer6]

Thanks @ityuhui, I've created #227 to review for changes. This change should allow pods logs to be retrieved again.

[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

[k8s-triage-robot]

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:

• 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 rotten
• Close this issue with /close
• Offer to help out with Issue Triage

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

/lifecycle rotten

[k8s-triage-robot]

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

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

/close not-planned

[k8s-ci-robot]

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

In response to this:

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

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

/close not-planned

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.