1.0.0 released - where are the migration docs?

[klippx]

Describe the bug

HttpError is no longer exported in 1.0.0

** Client Version **
1.0.0

To Reproduce
Prior to 1.0.0:

import * as k8s from '@kubernetes/client-node';

try {
  // do something with k8s
} catch (e) {
  if (e instanceof k8s.HttpError) {
    console.error(e.body);
  }
}

Expected behavior
If HttpError is not exported, I would be happy to see any upgrade docs state what the replacement is.

[brendandburns]

1.0.0 marks a major switch in the HTTP backend from request which has been deprecated for years to node-fetch which is still supported.

Unfortunately, there's breaking changes all over the place as a result of this switch. We would definitely love help in authoring a migration guide, at this point the best thing to do is to look at the examples in the release-1.x branch:

https://github.com/kubernetes-client/javascript/tree/release-1.x/examples

[brendandburns]

There's also fairly extensive discussion here:

#414

[cjihrig]

HttpError is no longer exported in 1.0.0

It looks like the new generator does have an HttpException class. However, it doesn't appear to actually be used anywhere in the code.

[jportner]

1.0.0 marks a major switch in the HTTP backend from request which has been deprecated for years to node-fetch which is still supported.

Unfortunately, there's breaking changes all over the place as a result of this switch. We would definitely love help in authoring a migration guide, at this point the best thing to do is to look at the examples in the release-1.x branch:

https://github.com/kubernetes-client/javascript/tree/release-1.x/examples

@brendandburns I looked to see if I could start taking a stab at this, but it appears that at least some of the examples might be incorrect/outdated?

• I see at least one reference to HttpError which is outdated

  javascript/examples/typescript/apply/apply-from-file-example.ts

  Line 42 in 0f5694e

  if (err instanceof k8s.HttpError && err.statusCode === 404) {

• I see tons of references to response response.body which is outdated

  javascript/examples/typescript/apply/apply-from-file-example.ts

  Lines 38 to 39 in 0f5694e

  	const response = await client.patch(spec);
  	created.push(response.body);

I can't find a single updated example that shows how to handle an error and determine if a resource doesn't exist...

[cjihrig]

I can't find a single updated example that shows how to handle an error and determine if a resource doesn't exist...

The examples definitely need a refresh. Here is a way of doing that in the new API:

const k8sApi = kc.makeApiClient(k8s.CoreV1Api);

try {
  const pod = await k8sApi.readNamespacedPod({ name: 'does-not-exist', namespace: 'default' });
  console.log(pod);
} catch (err) {
  const isNotFoundError = err instanceof k8s.ApiException && err.code === 404;
  console.log(isNotFoundError);
}

The ApiException type also has a .body property that includes more details:

'{"kind":"Status","apiVersion":"v1","metadata":{},"status":"Failure","message":"pods \\"does-not-exist\\" not found","reason":"NotFound","details":{"name":"does-not-exist","kind":"pods"},"code":404}\n'

Unfortunately, you currently have to JSON.parse() that field since it is a JSON string instead of an object.

[cjihrig]

Shameless plug, but I have been porting some Golang K8s utilities to Node.js. These functions in particular can be used to check error types. I just published an updated version of them that should work with v0.x and v1.x. It would look something like this:

import * as k8s from '@kubernetes/client-node';
import { apimachinery } from '@kubenode/controller-runtime';

const kc = new k8s.KubeConfig();
kc.loadFromDefault();

const k8sApi = kc.makeApiClient(k8s.CoreV1Api);
try {
  const pod = await k8sApi.readNamespacedPod({ name: 'does-not-exist', namespace: 'default' });
  console.log(pod);
} catch (err) {
  console.log(apimachinery.errors.isNotFound(err));
}

[brendandburns]

We'd be happy to take PRs updating the examples. A lot of them were ported over and as long as they compiled they were assumed to be "working"

That's clearly not an awesome way to determine if they are correct. Help cleaning them up would be appreciated.

[koooge]

Hi there, how do we migrate patch APIs? It looks like patch-example.js uses the internal PromiseMiddlewareWrapper as mentioned in #754.