search

cloudydeno / deno-kubernetes_client

Typescript library for accessing a Kubernetes API server
https://deno.land/x/kubernetes_client
Apache License 2.0
18 stars 4 forks source link

Improve Windows experience with USERPROFILE env #1

Closed jhannes closed 3 years ago

jhannes commented 3 years ago

On windows, the HOME environment variable is not generally set. Instead, the variable USERPROFILE points to the user's home directory where the .kube/config will be located

danopia commented 3 years ago

Looks look a straightforward contribution, thanks!

Would USERPROFILE be missing for any standard case? The fallback when no value is found is currently *nix-specific, which is fine if Windows always sets USERPROFILE.

jhannes commented 3 years ago

I am pretty sure that any Windows system that doesn't set it is quite broken, so there isn't much point of a fallback

danopia commented 3 years ago

Thanks for the contribution; v0.2.1 is tagged now and available on /x/.

Did you have any other issues or holdups trying out this library & the accompanying https://github.com/cloudydeno/deno-kubernetes_apis? I'd love to make sure they work well for most needs. Given that this issue seems easily worked around by setting HOME=$USERPROFILE I assume you got past it 😃

jhannes commented 3 years ago

@danopia I'm using the library for my still experimental project https://github.com/jhannes/hugin-cluster-radar. I have only used one feature of the library: coreApi.watchPodListForAllNamespaces(). I found the library intuitive and simple to use and the fix here was just to ease testing before deploying into my cluster.

I am still in the early testing phases of my project. I have noticed that sometimes the pods are restarted and my code doesn't detect it. I've had to prioritize other work so I haven't investigated properly, but if there is a problem with deno-kubernetes-client, I'll be sure to let you know. :-)

danopia commented 3 years ago

Ah cool, watching cluster resources 😄 almost my favorite part of the API bindings actually. I think it's worth writing up blog posts about using Deno to observe & act on Kubernetes since most everyone has been using Golang for this sort of thing, unfortunately blogging has been pretty low down on my priorities.

It looks like you're using the whole Reflector setup which is good. Given that, I don't think there should be a way to 'lose' information over than being disconnected at the time events happen (because the resync afterwards can skip in-between states). I usually post-process Reflector in my projects to debounce events and/or ignore modifications that I don't care about to keep the noise down.

I took a peek through your code and it looks like for modification events, only pod phase is updated. If you're picking up pod restarts by waiting for PodPhase to bounce away from Running and back then it's technically possible to miss the event I think. That's not a great heuristic to go by for a "restart" (assuming we're talking about the same thing, a container exiting and being replaced). I believe it would be most reliable to pay attention to each container's restartCount and catch any increment.

Anyway, if you do some debugging and still see some weird watch behaviour, this Reflector is a completely custom design I wrote for my needs (not related to the golang Reflector from upstream) so I'm sure there's things that can be improved with it. Cheers