I tested on 1.10 and 1.7 and they both worked. I don't have an older k8s cluster version to test on.

Thanks for the detailed research, and the fix!

LGTM if we are ok to drop <1.2, which we probably are.
I suspect which format to use could be gleaned from discovery info (?) but I doubt it's worth it unless we're to keep testing kubeclient with ancient versions.

@moolitayer what do you think? Do we even have a documented min supported kubernetes version?

We currently have this note in the README https://github.com/abonas/kubeclient#supported-kubernetes-versions.

I'm okay with dropping kubetnetes versions who are no longer receiving patches. I think 1.7 is the oldest supported one. Should be documented.

cc @jeremywadsack @grosser @kirs @deads2k

cc @pravi ^^

GKE doesn't support anything older than 1.7, according to their documentation (updated a week ago).

That said, I checked the reported valid versions (for create or update) on a zone in each region and they consistently report only 1.8 and 1.9 for master and 1.5, 1.6, 1.7, 1.8, and 1.9 for nodes. I assume we only need to concern ourselves with master here because this related to the API connection.

I changed the supported version text to be the last 3 versions. Hopefully this can get into a release soon, as I would expect 1.10 to be available in GKE soon.

1.10 is now GA on GKE: https://cloudplatform.googleblog.com/2018/05/Google-Kubernetes-Engine-1-10-is-generally-available-and-ready-for-the-enterprise.html

Sorry for delay silence. This looks good, but I can't escape the conclusion that while minor, a known deliberate incompatibility to k8s version that used to work requires a major version bump.
So I want to release existing compatible improvements in a 3.1.0 first (#328), hopefully on Sunday, and then will merge this.

Sorry, this was long overdue. I'll try to release soon.

Sorry again, I really dropped the ball on this. Finally releasing today (#344).

One thing I wasted too much time on is running old k8s versions and recording discovery info.

For the record, IF we wanted to make this backward-compatible, it may be possible to choose old vs new URL format from discovery info:
https://cben.github.io/kubernetes-discovery-samples/openshift-origin-v1.1.1/api/v1/ declares "pods/proxy" resource.
https://cben.github.io/kubernetes-discovery-samples/openshift-origin-v1.2.0/api/v1/ declares "pods/proxy", "nodes/proxy", "services/proxy" resources
https://cben.github.io/kubernetes-discovery-samples/openshift-origin-v1.3.0/api/v1/ and later also declare "pods/proxy", "nodes/proxy", "services/proxy" resources.

So, did new format appear in 1.3 as we thought or already 1.2? Is 1.2 broken or only <=1.1?
Well, I gave up testing :-( I tried to test proxying on the semi-fake openshift 1.2, 1.3 I brought up but it wasn't fully functional and I couldn't get proxying to work even with curl... Stock kubernetes even harder to test, Minikube won't go older than 1.3 and so far I only managed to run 1.7+...

Anyway, if it's impractical to test 1.2, it's good to declare it unsupported :-)

PSA: As you can see my response time is not good lately :-(. Mooli has switched to a new job and likely won't have time for kubeclient. I'd be happy if anyone wants to join as maintainer.

Anyway, if it's impractical to test 1.2, it's good to declare it unsupported :-)

I think that's perfectly reasonable.

Can travis be scripted to spin up a matrix of openshift, minkube, and gke clusters to run e2e tests? Would RedHat be willing to provide commercial support? I don't expect the costs to be that high, but it might exceed the free tiers at some point.

I am not sure if I'm of much help because I don't really know anything about the Kubernetes API. Happy to be a resource for GKE as time allows.

this testing process sounds useful, can you document how you do this ?
(tools to spin up old clusters / what to test etc ... ideally that would be automated, but docs would be a good step forward)

The scripts at https://github.com/cben/kubernetes-discovery-samples/tree/master/tools spin up a all-in-one openshift / minikube, run scrape.sh, and take them down. Comment out the "down" at the end and you can interact with the "cluster".
Nothing magic, it's basically one-liner (though long one) to start minikube / openshift directly.

I hope to start consuming these recorded discovery jsons from multiple versions in kubeclient unit tests (via webmock?).

Can travis be scripted to spin up a matrix of openshift, minkube, and gke clusters to run e2e tests?

In theory yes, Travis in VM mode has docker, which allows minikube in --vm-driver=none mode (as should also allow the openshift all-in-one container):
https://blog.travis-ci.com/2017-10-26-running-kubernetes-on-travis-ci-with-minikube
The main part missing is actually writing some integration tests :-)
Closest we have is test_guestbook_go.rb (currently runs against a VCR).