hub/conat: discover via k8s api

[haraldschilly]

No description provided.

[haraldschilly]

I tested this in onprem, I get

cocalc:debug:conat:core:server scan: remote http://10.124.0.25:5000 knows about Set(2) { 'http://10.124.0.25:5000', 'http://10.124.2.31:5000' }

which looks promising, and there are two routers – but the health check still fails.

[williamstein]

This is a 68MB dependency that is not needed except in kucalc, so there's no way I'm merging this into the main cocalc repo, having spent so much time recently removing packages (about 100):

mkdir x
cd x
pnpm init
pnpm i @kubernetes/client-node
du -sch .
--> 68M     total

The options I can think of:

1. Somehow move this code to only be in kucalc (similar to how manage works).
2. Make a new kucalc package in this repo that has this code (someday rewrite and move the manage code there), and do NOT install/build it by default and make sure nothing depends on it.
3. Rewrite dns-scan-k8s-api.ts to just directly call the API instead of using this 68MB wrapper library. This is probably easy to autoconvert using AI from what you wrote, but it's harder to read, maintain, and uglier. It would have no dependencies and work fine.

Personally, I think 2 is the best approach. E.g., regarding manage-* there is no need to keep that code secret, and having it in this repo (and in typescript) would help ensure things stay aligned. What do you think about the above options? Is there another one I'm missing?

NOTE: I'm well aware that there is a similar problem in our server package regarding the -- also from Google -- very, very heavy Google cloud api client. It might also make sense to move the compute server api code to a separate package, which only gets built in deployments that will make use of compute servers. We can make cocalc much more lightweight. E.g., this package https://www.npmjs.com/package/@cocalc/compute-server is 32MB, and has everything needed to run the compute server daemon, which includes the @cocalc/project package...

[williamstein]

All that said, even with option 2, this 68MB is still an extra 68MB that has to get copied all over the place whenever any hub gets deployed anywhere. I'm not thrilled about that.