Updating to version 0.11.0 broke working functionality when using 0.10.2

[rvillane]

Hi, we have a very basic app that executes a kubectl patch command to add an annotation on a deployment, when using v0.10.2 works fine, but when using v0.11.0 it doesn't throw any errors but the patching action to add the annotation is not performed. Looking at changes introduced on v0.10.3 an v0.11.0 noticed that K8s openAPI spec was upgraded from v1.13.10 to v1.15.5.

Our clusters are currently in k8s v1.13.9, would the openAPI update explain why our app stopped working when using 0.11.0 ?

thanks for any clarification that can be provided

[brendandburns]

It's definitely possible. Is there any chance you can capture the body in both cases and see what/if the difference is?

My guess is that the default patch content-type changed between versions.

[rvillane]

Any recommendation on how to capture the body ? I definitely can try but I just have seen the response being captured, not the body.

Also, in case it helps, my code is listed below, notice how I needed to add the content-type header explicitly.

const k8s = require('@kubernetes/client-node');

const kc = new k8s.KubeConfig();
kc.loadFromDefault();
const k8sApi = kc.makeApiClient(k8s.ExtensionsV1beta1Api);
const deploymentName = process.env.DEPLOYMENT_NAME;
const namespace = process.env.NAMESPACE;

async function redeployPods() {
    const deployment = {
        spec: {
            template: {
                metadata: {
                    annotations: {
                        my_annotation: new Date().toISOString(),
                    },
                },
            },
        },
    };

    // required to avoid HTTP 415 errors
    const headers = { 'content-type': 'application/strategic-merge-patch+json' };
    return k8sApi.patchNamespacedDeployment(deploymentName, namespace, deployment, undefined, undefined, { headers });
}

[fejta-bot]

Issues go stale after 90d of inactivity. Mark the issue as fresh with /remove-lifecycle stale. Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta. /lifecycle stale

[brendandburns]

/lifecycle frozen

[rivernews]

Hi, coming from #444 and #413, which both seems that object typing is used for port property. In my case this prevents me from getting tsc transpile Typescript successfully which would stop the entire project.

@brendanburns I think I have some bandwidths to dig into this and possibly create a PR, but can you provide a bit more info? For example, how swag spec is affecting the typings for Typescript, etc? Thanks.

[polaroi8d]

Any update on this? I would like to define a new V1Service object and the targetPort is an object type and I can't build it. Error: Type 'number' is not assignable to type 'object'.ts(2322)