Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Watch Support #4

Open
deas opened this issue Apr 13, 2020 · 6 comments
Open

Watch Support #4

deas opened this issue Apr 13, 2020 · 6 comments

Comments

@deas
Copy link

deas commented Apr 13, 2020

Been playing with k8s-api for a while and I really like it.

However, I need watch support. Saw the docstring mentioning kubernetes/kubernetes#50857. Watch is the gateway to operators, and I am wondering how to get support in.

I also like http-kit in general but it appears to lack maintenance and it also appears to require some patching to get watch working. The next issue I encountered was lack of tls support with Java 11 in the stable version. Not super important at the moment but I'd expect graal support to be a problem as well.

Don't get me wrong: I am not saying we should be departing from http-kit immediately. I'd be fine using something else to watch for now. However, I'd also be willing to help getting support into k8s-api. ;)

Do you have any long term vision with regards to the http library/libraries to use in k8s-api?

@deas
Copy link
Author

deas commented Apr 13, 2020

Played a little more. :)

https://github.com/martinklepsch/clj-http-lite works with watch:

    (let [res (http-light/get "http://127.0.0.1:8001/api/v1/namespaces/default/pods?watch=true"
                             {:as :stream})
          rdr (-> (:body res) (InputStreamReader. "UTF8") BufferedReader.)
          items (parsed-seq rdr)]
      (doseq [item items] (println item)))

Swapping clj-http for clj-http-lite in martian does not appear to be difficult either. Not saying things will be working though. Will give it a try ;)

Happy easter!

@RafaeLeal
Copy link
Collaborator

Hey! Thanks for the report :)
Yeah, this is very annoying in fact.. the problem is that the Kubernetes API doesn't follow HTTP 1.1 spec on chunked responses. So it's not http-kit limitation actually 😞 .

I'm considering following martian approach to decouple from http implementation.. but I'm not sure yet.

@deas
Copy link
Author

deas commented Apr 24, 2020

I got watch and client pluggability working in k8s-api. When using watch, the client gets a (blocking) sequence of maps. This works with clj-http-lite and iirc also with clj-http. It does not yet work with httpkit, but there are no regressions in the httpkit implementation either.

At the moment, the k8s-api detects the client implementation from the environment (for compatibility). Not sure if this is what we want or whether we want to set it explicitly. There are also other areas which do not yet look clean to me. Would be great if you could check so the changes get into your master branch.

Feel free to check: https://github.com/deas/k8s-api/commits/pluggable-client

BTW: I landed a commit adding clj-http-lite in martian master. ;)

@Dangercoder
Copy link

Dangercoder commented Dec 16, 2020

Any news on this? I'm in need of the watch functionality as well.

edit: I embraced java interop and went with https://github.com/fabric8io/kubernetes-client for the --watch functionality

@blak3mill3r
Copy link

Glad to see someone working on this! I did an experiment using the watch k8s API from clojure a while back. It is 3+ years old and it might not be relevant. I mention it anyway in case it is of some use/interest.

https://github.com/blak3mill3r/keenest-rube/blob/master/src/rube/request.clj#L61 I used aleph.http for the chunked response parsing and wound up with a core.async channel of EDN from k8s.

@olymk2
Copy link

olymk2 commented Jun 23, 2021

nice to see this is being worked on any reason the work in @deas branch cant be implemented watch would be really nice to see.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants