Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Support both TPR and CRD with custom objects spec #283

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

Merged
merged 3 commits into from
Jul 7, 2017

Conversation

mbohlool
Copy link
Contributor

@mbohlool mbohlool commented Jul 5, 2017

Fixes #251

should also fix #280

@k8s-ci-robot k8s-ci-robot added the cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. label Jul 5, 2017
@mbohlool mbohlool requested a review from jonathan-kosgei July 5, 2017 22:39
@mbohlool
Copy link
Contributor Author

mbohlool commented Jul 5, 2017

cc @djmckinley

@mbohlool
Copy link
Contributor Author

mbohlool commented Jul 5, 2017

cc @enisoc

Copy link

@enisoc enisoc left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM overall. Some questions below.

"type": "string"
},
{
"name": "kind",
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is "kind" just shorthand for the plural resource name? In CRD we distinguish between the kind (CronJob), the singular (cronjob), and plural resource name (cronjobs). The plural resource name is technically the one that goes in the URL here, and it doesn't have to be related to the other names at all (they can all be specified independently). So if you wanted, you could define a CRD with kind "CronJob" and plural resource name "moomoofarm" and the latter would go in the URL.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, this is the one goes into URL. Do you have any suggestion for its name that make sense in both CRD and TPR world?

"consumes": [
"*/*"
],
"produces": [
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does this tell clients what content types they are allowed to request? If so, we should be careful what we list because custom objects served by CRD don't support protobuf. I'm not sure if they even support yaml; I'd be surprised if they do.

If this spec gets used for custom objects backed by an aggregated API server, there's no reason it couldn't support protobuf and yaml, but then I would expect them to export their own spec at that point. This generic spec makes more sense for low-effort integrations like CRD.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Make sense. Will remove yaml and proto.

"produces": [
"application/json",
"application/yaml",
"application/vnd.kubernetes.protobuf"
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same here about the content types for protobuf and yaml.

"name": "group",
"in": "path",
"required": true,
"description": "The Custom object's group name",
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some of the usages of "custom object" in this spec make more sense to me as "custom resource". We intentionally added the "D" in "CRD" to distinguish the custom resource from the thing that installs it (the custom resource definition).

The way I think of it is: the CRD installs a custom resource, which is the location in the API where you can store custom objects.

@mbohlool
Copy link
Contributor Author

mbohlool commented Jul 5, 2017

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

@djmckinley
Copy link

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.

@mbohlool
Copy link
Contributor Author

mbohlool commented Jul 6, 2017

@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.

@enisoc
Copy link

enisoc commented Jul 6, 2017

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"
}

@mbohlool
Copy link
Contributor Author

mbohlool commented Jul 6, 2017

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).

@mbohlool
Copy link
Contributor Author

mbohlool commented Jul 7, 2017

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 mbohlool merged commit 917ec63 into kubernetes-client:master Jul 7, 2017
@ebbeelsborg
Copy link

ebbeelsborg commented Oct 25, 2017

@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!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
cncf-cla: yes Indicates the PR's author has signed the CNCF CLA.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

ThirdPartyResourcesApi.delete_third_party_resource() Migrate ThirdPartyResources to CustomResourceDefinitions
5 participants