`kubectl get` and `kubectl describe` extensions #308

pwittrock · 2017-01-30T21:40:26Z

…ns for non-compiled in types.

@fabianofranz The sig-service-catalog was going to fork kubectl and compile in custom types for get and describe to work. I really don't like this solution, and think we could support their needs in a simple way.

Would you be open to discussing this on Wednesday?

sig-service-catalog has agreed to donate the development resources to implement. @simonleung8

…ns for non-compiled in types.

pwittrock · 2017-01-30T21:53:34Z

FYI: @duglin

duglin · 2017-01-30T23:51:13Z

thanks @pwittrock!

deads2k · 2017-01-31T14:07:57Z

get and describe function based on resource builders (as distinct from create). If you allow people to claim a name under kubectl get, you'll effectively "steal" that name from anyone who adds an aggregated API server with that resource. I think that would be a bad outcome.

philips · 2017-01-31T14:25:15Z

Question I would like to see answered: How does this behavior play with third-party resources and the naming scheme there? Which takes precedence?

deads2k · 2017-01-31T14:42:52Z

Question I would like to see answered: How does this behavior play with third-party resources and the naming scheme there? Which takes precedence?

Currently, thirdpartyresources are not special. They are exposed via discovery and the kubectl resourcebuilder inspects discovery to find mappable names (with some significant priority and autocompletion rules). If we were allow extensions under kubectl get in the CLI, someone could claim kubectl get operator and any TPR named operator would be screwed.

philips · 2017-01-31T14:53:45Z

@deads2k Well, that is partially true as you can have two third party resources that are both called "operator". In that case someone can still use kubectl get operator.third-party.example.com/v1 to find their specific resource.

deads2k · 2017-01-31T15:01:01Z

@deads2k Well, that is partially true as you can have two third party resources that are both called "operator". In that case someone can still use kubectl get operator.third-party.example.com/v1 to find their specific resource.

True, but in practice claiming a section of the value-space via extension like this feels like cheating. We wouldn't let people do it in tree because of name stealing, it doesn't seem like we'd want to allow it from out of tree.

liggitt · 2017-01-31T15:07:07Z

Well, that is partially true as you can have two third party resources that are both called "operator".

Right, and the decision about which takes precedence is up to the cluster-admin of the server hosting the resources. Making the generic kubectl operations work consistently via discovery puts control of precedence for a particular server in the cluster-admin's hands. Two users running kubectl get operator against the same server and getting different objects seems like a bad idea.

liggitt · 2017-01-31T15:09:37Z

contributors/design-proposals/sig-cli/get-describe-apiserver-extensions.md

+Allow the apiserver to define the type specific columns that will be
+printed using the open-api swagger.json spec already fetched by kubectl.
+This provides a limited describe to only print out fields on the object
+and related events.


how do you envision this interacting with kubernetes/kubernetes#33900 ?

Good question. I guess I don't fully understand how that proposal is intended to interact with the swagger schema. I suspect that this proposal is a much lighter version of the sub-pieces of kubernetes/kubernetes#33900 dealing with getting metadata about objects.

liggitt · 2017-01-31T15:10:54Z

contributors/design-proposals/sig-cli/get-describe-apiserver-extensions.md

+Define the open-api extensions `x-kubernetes-kubectl-get-columns` and
+`x-kubernetes-kubectl-describe-columns`.  These extensions have a
+string value containing the columns to be printed by kubectl.  The
+string format is the same as the `--custom-columns` for `kubectl get`.


we don't have openapi schemas for third party resources... do we anticipate adding that in the future?

Thanks for pointing that out. I just added some comments about this. The short answer is - Yes I would like to add support for TPR. My initial thought is that this can be done through an annotation on the TPR. If we implement this proposal by hooking into the RestMapper, supporting TPR should be relatively clean. If we hack this proposal in, then it would be less clean.

…mpiled in types

pwittrock · 2017-01-31T17:47:03Z

@deads2k @philips

PTAL. I have added sections to the implementation part that should clarify things.

TL;DR:

@philips TPRs are not being targeted for the alpha version since they will never appear in the swagger.json, but their future integration is being considered as part of the implementation considerations.

@deads2k I wasn't planning on overriding the resource builder, but instead either integrating with it by having it parse the extensions when present.

liggitt · 2017-01-31T18:01:06Z

integrating with it by having it parse the extensions when present.

would you envision that happening at the two spots we print objects we don't otherwise know about?

https://github.com/kubernetes/kubernetes/blob/e0337b1d0c8877e899888325cc3818cee600e6dd/pkg/kubectl/resource_printer.go#L2431-L2454

and

https://github.com/kubernetes/kubernetes/blob/e0337b1d0c8877e899888325cc3818cee600e6dd/pkg/kubectl/describe.go#L188-L214

pwittrock · 2017-01-31T22:37:42Z

@liggitt Yes that is what I was thinking. Not certain of the best way to plumb the data there though.

fabianofranz · 2017-03-08T19:56:08Z

This seems to have some overlapping with #363.

smarterclayton · 2017-03-08T20:39:45Z

The intent would be that the implementation of this be done on the server side, which simplifies clients (they don't have to look at swagger at all).

adohe-zz · 2017-03-15T13:46:45Z

contributors/design-proposals/sig-cli/get-describe-apiserver-extensions.md

+This provides a limited describe to only print out fields on the object
+and related events.
+
+**Note:** This solution will only work for types compiled into the apiserver


include federated apiservers?

bgrant0607 · 2017-04-14T18:03:35Z

cc @kubernetes/sig-cli-proposals @kubernetes/sig-api-machinery-proposals @kubernetes/sig-service-catalog-proposals

bgrant0607 · 2017-04-14T18:07:50Z

@pwittrock @fabianofranz @smarterclayton Maybe this should be hashed out in a joint SIG CLI / API machinery meeting? Or choose one of the meetings?

bgrant0607 · 2017-04-14T18:26:05Z

In general, I'd like OpenAPI to provide rich, complete, accurate info for clients, but for the most commonly needed functionality to be implemented in the apiserver and controllers (e.g., GC). kubernetes/kubernetes#12143

Example:

Schema validation today is done in the client using OpenAPI, but I'd like to provide this optionally in the server: kubernetes/kubernetes#5889. Multi-platform orchestrators like ManageIQ, Ansible, Puppet, Google Deployment Manager, etc. may choose to use OpenAPI, but simpler K8s-specific clients should be able to request schema validation. We don't want to have to write that in 6+ languages (Go, Python, Java, Javascript, Ruby, PHP, ...).

In this case, as I commented https://github.com/kubernetes/community/pull/363/files#r111605582, I envision resource-specific computation and filtering to happen in the server, and rendering to be done in the client.

For TPR, I imagine accepting the same OpenAPI format that K8s returns for built-in resources, whether from the primary apiserver or aggregated ones. That would support schema validation, declarative value validation and defaulting (kubernetes/kubernetes#25460), get, describe, diff, merge, apply, edit, explain, external orchestrators, client-library generation, documentation generation, etc. We shouldn't invent yet another schema for enabling those things, other than our types.go-based annotations (currently a combination of tags and comments), until/unless that's replaced by another IDL.

cc @lavalamp @cheftako @enisoc @pwittrock @mbohlool

@pmorie

…d_describers Automatic merge from submit-queue (batch tested with PRs 44222, 44614, 44292, 44638) Smarter generic getters and describers Makes printers and describers smarter for generic resources. This traverses unstructured objects and prints their attributes for generic resources (TPR, federated API, etc) in `kubectl get` and `kubectl describe`. Makes use of the object's field names to come up with a best guess for describer labels and get headers, and field value types to understand how to better print it, indent, etc. A nice intermediate solution while we don't have [get and describe extensions](kubernetes/community#308). Examples: ``` $ kubectl get serviceclasses NAME KIND BINDABLE BROKER NAME OSB GUID user-provided-service ServiceClass.v1alpha1.servicecatalog.k8s.io false ups-broker 4f6e6cf6-ffdd-425f-a2c7-3c9258ad2468 ``` ``` $ kubectl describe serviceclasses/user-provided-service Name: user-provided-service Namespace: Labels: <none> Annotations: FOO=BAR openshift.io/deployment.phase=test OSB Metadata: <nil> Kind: ServiceClass Metadata: Self Link: /apis/servicecatalog.k8s.io/v1alpha1/serviceclassesuser-provided-service UID: 1509bd96-1b05-11e7-98bd-0242ac110006 Resource Version: 256 Creation Timestamp: 2017-04-06T20:10:29Z Broker Name: ups-broker Bindable: false Plan Updatable: false OSB GUID: 4f6e6cf6-ffdd-425f-a2c7-3c9258ad2468 API Version: servicecatalog.k8s.io/v1alpha1 Plans: Name: default OSB GUID: 86064792-7ea2-467b-af93-ac9694d96d52 OSB Free: true OSB Metadata: <nil> Events: <none> ``` **Release note**: ```release-note Improved output on 'kubectl get' and 'kubectl describe' for generic objects. ``` PTAL @pmorie @pwittrock @kubernetes/sig-cli-pr-reviews

pwittrock · 2017-04-19T20:20:12Z

Exact swagger tag names TBD

add some docs PR links

`kubectl get` and `kubectl describe` extensions

No feature proposal for kubectl get and kubectl describe extensio…

a1cf951

…ns for non-compiled in types.

pwittrock assigned fabianofranz and pmorie Jan 30, 2017

k8s-ci-robot added the cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. label Jan 30, 2017

pwittrock changed the title ~~No feature proposal for kubectl get and kubectl describe extensio…~~ kubectl get and kubectl describe extensions Jan 30, 2017

liggitt reviewed Jan 31, 2017

View reviewed changes

pwittrock added 4 commits January 31, 2017 09:06

Add implementation details

1aa9282

Add information about what to do when extensions are available for co…

39dbe85

…mpiled in types

Add version

f3d5c99

Update proposal to use generalize extensions

ff39a62

fix typo

af50771

fabianofranz mentioned this pull request Mar 8, 2017

Proposal: Server-side kubectl get #363

Merged

adohe-zz reviewed Mar 15, 2017

View reviewed changes

fabianofranz mentioned this pull request Apr 7, 2017

Smarter generic getters and describers kubernetes/kubernetes#44222

Merged

pwittrock mentioned this pull request Apr 19, 2017

WIP: Proposal for moving "printers" (kubectl get) to the server kubernetes/kubernetes#29472

Closed

pmorie mentioned this pull request May 8, 2017

Make it possible to add porcelain commands to kubectl for service-catalog kubernetes-retired/service-catalog#806

Closed

pwittrock merged commit fb47a5a into kubernetes:master Jun 1, 2017

shyamjvs pushed a commit to shyamjvs/community that referenced this pull request Sep 22, 2017

Merge pull request kubernetes#308 from mlycore/patch-2

8567042

add some docs PR links

MadhavJivrajani pushed a commit to MadhavJivrajani/community that referenced this pull request Nov 30, 2021

Merge pull request kubernetes#308 from pwittrock/get-describe-extensions

1f04872

`kubectl get` and `kubectl describe` extensions

danehans pushed a commit to danehans/community that referenced this pull request Jul 18, 2023

Add scottilee to Istio org (kubernetes#308)

5b0f3ca

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

`kubectl get` and `kubectl describe` extensions #308

`kubectl get` and `kubectl describe` extensions #308

pwittrock commented Jan 30, 2017

pwittrock commented Jan 30, 2017

duglin commented Jan 30, 2017

deads2k commented Jan 31, 2017

philips commented Jan 31, 2017

deads2k commented Jan 31, 2017

philips commented Jan 31, 2017

deads2k commented Jan 31, 2017

liggitt commented Jan 31, 2017 •

edited

Loading

liggitt Jan 31, 2017

pwittrock Jan 31, 2017

liggitt Jan 31, 2017

pwittrock Jan 31, 2017

pwittrock commented Jan 31, 2017

liggitt commented Jan 31, 2017

pwittrock commented Jan 31, 2017

fabianofranz commented Mar 8, 2017

smarterclayton commented Mar 8, 2017

adohe-zz Mar 15, 2017

bgrant0607 commented Apr 14, 2017

bgrant0607 commented Apr 14, 2017

bgrant0607 commented Apr 14, 2017 •

edited

Loading

pwittrock commented Apr 19, 2017

kubectl get and kubectl describe extensions #308

kubectl get and kubectl describe extensions #308

Conversation

pwittrock commented Jan 30, 2017

pwittrock commented Jan 30, 2017

duglin commented Jan 30, 2017

deads2k commented Jan 31, 2017

philips commented Jan 31, 2017

deads2k commented Jan 31, 2017

philips commented Jan 31, 2017

deads2k commented Jan 31, 2017

liggitt commented Jan 31, 2017 • edited Loading

liggitt Jan 31, 2017

Choose a reason for hiding this comment

pwittrock Jan 31, 2017

Choose a reason for hiding this comment

liggitt Jan 31, 2017

Choose a reason for hiding this comment

pwittrock Jan 31, 2017

Choose a reason for hiding this comment

pwittrock commented Jan 31, 2017

liggitt commented Jan 31, 2017

pwittrock commented Jan 31, 2017

fabianofranz commented Mar 8, 2017

smarterclayton commented Mar 8, 2017

adohe-zz Mar 15, 2017

Choose a reason for hiding this comment

bgrant0607 commented Apr 14, 2017

bgrant0607 commented Apr 14, 2017

bgrant0607 commented Apr 14, 2017 • edited Loading

pwittrock commented Apr 19, 2017

`kubectl get` and `kubectl describe` extensions #308

`kubectl get` and `kubectl describe` extensions #308

liggitt commented Jan 31, 2017 •

edited

Loading

bgrant0607 commented Apr 14, 2017 •

edited

Loading