cc @djmckinley

cc @enisoc

@enisoc updated with your comments. Can you take another look?

This looks good as far as fixing #280.

I have a couple of questions about the "list" functions, though.

The previous third_party_resources_api.py module appeared to list third party resources across all namespaces. Now, with the custom_objects_api.py module, the list functions for namespaced CRs seem to support listing namespaced custom objects only in a single namespace. Is there a reason there is not a "list_namespaced_custom_objects_for_all_namespaces" function like there are for the various core resources? (For example, does "list_cluster_custom_objects" perhaps do that if the object kind it identifies is a namespaced object?)

Second, is there a reason that the list functions do not have the optional parameters, "label_selector" and "resource_generation" that are present on the list functions for core objects?

Both the ability to list objects in a single namespace, or across all namespaces, and the ability to filter by label and resource_generation would be very useful for my use case.

@djmckinley both good points. On your first point, list_cluster_custom_objects should do the trick, if you can give it a try and see if that is the case, it would be awesome. The naming prefered CRDs as they are the way to go and TPRs will be removed in next version of kubernetes (1.8).

On your second point, you are right, I will add those optional parameters to all list operations.

LGTM other than the additional list options mentioned above.

I verified that you can list namespaced custom objects across all namespaces by hitting the non-namespaced resource path:

$ kubectl get --raw /apis/stable.example.com/v1/crontabs/ | json_pp
{
   "kind" : "CronTabList",
   "metadata" : {
      "resourceVersion" : "1805",
      "selfLink" : "/apis/stable.example.com/v1/crontabs/"
   }, 
   "items" : [
      {
         "spec" : {
            "image" : "old-image",
            "cronSpec" : "* * * * /5"
         }, 
         "apiVersion" : "stable.example.com/v1",
         "kind" : "CronTab",
         "metadata" : {
            "deletionGracePeriodSeconds" : null,
            "creationTimestamp" : "2017-07-06T18:52:03Z",
            "namespace" : "default",
            "uid" : "3385cb16-627c-11e7-9d68-a0481c9805b1",
            "deletionTimestamp" : null,
            "resourceVersion" : "1363",
            "clusterName" : "",
            "name" : "my-new-cron-object",
            "selfLink" : "/apis/stable.example.com/v1/namespaces/default/crontabs/my-new-cron-object"
         }
      },
      {
         "spec" : {
            "cronSpec" : "* * * * /5",
            "image" : "my-awesome-cron-image"
         },
         "apiVersion" : "stable.example.com/v1",
         "kind" : "CronTab",
         "metadata" : {
            "name" : "crontab-1",
            "clusterName" : "",
            "selfLink" : "/apis/stable.example.com/v1/namespaces/ns2/crontabs/crontab-1",
            "creationTimestamp" : "2017-07-06T18:56:00Z",
            "resourceVersion" : "1796",
            "deletionTimestamp" : null,
            "uid" : "c05f8fd5-627c-11e7-9d68-a0481c9805b1",
            "namespace" : "ns2",
            "deletionGracePeriodSeconds" : null
         }
      }
   ],
   "apiVersion" : "stable.example.com/v1"
}

Thanks @enisoc and @djmckinley. I need to close this PR and send the PR agains kubernetes-client/gen repo (we moved to use that for generation).

Re-opening this PR (to keep history of this change) with just updating the client after gen repo PR is merged.
@djmckinley can you try your example again? it should work now.

@mbohlool Thanks for doing this; it's an important issue. There is one thing I can't get to work though.

Main question: How do I manage CRDs with client-python 3.0?

Background
I can manage the CRD objects with the new CustomObjectsApi, which works nicely. I can also still manage TPR definitions via the ExtensionsV1beta1Api, but that API seems to not work directly for CRD definitions (YAML with "Kind: CustomResourceDefinition").

Here is an example cluster response:

HTTP response body: {"kind":"Status","apiVersion":"v1","metadata":{},"status":"Failure","message":"CustomResourceDefinition in version \"v1beta1\" cannot be handled as a ThirdPartyResource: no kind \"CustomResourceDefinition\" is registered for version \"apiextensions.k8s.io/v1beta1\"","reason":"BadRequest","code":400}

I'm calling the method "create_third_party_resource" with the CRD YAML as its body on a client.ExtensionsV1beta1Api instance.

I'm on k8s 1.7.4.

Ideas:
Should the new ApiExtensionsV1beta1Api introduced for k8s 1.8 in v.4.0 of client-python (support in 4.0) be ported backwards to v.3.0 (k8s 1.7), am I to use v.4.0 with k8s 1.7, or am I just supposed to transform (strip a few fields such as scope etc.) the CRD def. to a TPR def. before calling "create_third_party_resource"?

(support in 3.0)

Thanks!