Proposal: better output when getting 3prs

[krancour]

Using k8s 1.3.5, and given the existence of a third party resource foo, querying for all resources of type foo in a namespace bar produces the following output:

$ kubectl get foo --namespace=bar
NAME             LABELS    DATA
my-foo           <none>    {"apiVersion":"foo.deis.io/v1","description":"...
your-foo         <none>    {"apiVersion":"foo.deis.io/v1","description":"...
our-fu           <none>    {"apiVersion":"foo.deis.io/v1","description":"...
kung-fu          <none>    {"apiVersion":"foo.deis.io/v1","description":"...

Contrast this to the output received when querying for any built-in resource type-- pods, for instance:

$ kubectl get pods --namespace=kube-system
NAME                            READY     STATUS    RESTARTS   AGE
kube-addon-manager-minikubevm   1/1       Running   0          15h
kubernetes-dashboard-zud5i      1/1       Running   0          15h

The latter case provides useful, contextually rich information about our pods, while the former case tells us nothing of value about our resources of type foo.

Given that a third party resource could represent anything and have any structure, there is obviously no one-size-fits all behavior that would represent any kind of improvement to this situation, however, what could work (unless this exists already and is not documented) is a mechanism whereby the definition of a third party resource could include a list of columns that should be returned with a get.

Hypothetically, that could look something like this:

apiVersion: extensions/v1beta1
kind: ThirdPartyResource
metadata:
  name: foo.deis.io
  labels:
    heritage: deis
description: "A foo is just a silly little  thing"
versions:
- name: v1
display:
- OWNER: spec.owner
- STATUS: status
wide-display:
- DESCRIPTION: description

Querying for all resources of type foo might then yield results like this:

$ kubectl get foo --namespace=bar
NAME             OWNER               STATUS
my-foo           me                  ok
your-foo         you                 ok
our-fu           us                  error
kung-fu          kwai chang caine    ok

Or with -o wide specified:

$ kubectl get foo --namespace=bar
NAME             OWNER               STATUS       DESCRIPTION
my-foo           me                  ok           This is my foo
your-foo         you                 ok           This is your foo
our-fu           us                  error        This is our foo
kung-fu          kwai chang caine    ok           This is Kung Fu

[zreigz]

I can work on this. I will take a look deeper into 3prs and I will try prepare some code proposal

[zreigz]

I've prepared some demo code here: https://github.com/zreigz/kubernetes/tree/third_party_resource_update
To test it you can create thirdpartyresources with display and wideDisplay metadata

tpr.yaml

apiVersion: extensions/v1beta1
kind: ThirdPartyResource
metadata:
  name: foo.deis.io
  labels:
    heritage: deis
description: "A foo is just a silly little  thing"
versions:
- name: v1
display:
  OWNER: metadata.name
  IMAGE: image
wideDisplay:
  DESCRIPTION: description

kubectl create tpr.yaml --validate=false

There is one problem with creating tpr resource because new fields can not be resolved

error validating data: [found invalid field wideDisplay for v1beta1.ThirdPartyResource, found invalid field display for v1beta1.ThirdPartyResource];

and I can not find solution how to fix it. The --validate=false solves the problem for demo purpose

Now you can add Foo instances
test1.yaml

apiVersion: "deis.io/v1"
kind: Foo
metadata:
  name: my-new-cron-object
cronSpec: "* * * * /5"
image: my-awesome-cron-image
description: "test description"

and

test2.yaml

apiVersion: "deis.io/v1"
kind: Foo
metadata:
  name: test2
cronSpec: "* * * * /5"
image: image2
description: "test2 description"

$ kubectl create -f test1.yaml
& kubectl create -f test2.yaml

The result is:

$ kubectl get foos
NAME                 KIND             IMAGE                   OWNER
my-new-cron-object   Foo.v1.deis.io   my-awesome-cron-image   my-new-cron-object
test2                Foo.v1.deis.io   image2                  test2

with wide flag

$ kubectl get foos -o wide
NAME                 KIND             IMAGE                   OWNER                DESCRIPTION
my-new-cron-object   Foo.v1.deis.io   my-awesome-cron-image   my-new-cron-object   test description
test2                Foo.v1.deis.io   image2                  test2                test2 description

so everything works as expected

TODO:

• fix validation problem
• clean the code
• create PR

[zreigz]

cc @cheld

[zreigz]

@deads2k @adohe @brendandburns Can you give some feedback. Is it worth to continue this or is it valuable for you ?

[deads2k]

As I recall, @pwittrock had a proposal to use swagger annotations to identify fields to display. There's also a proposal to handle kubectl get server-side using a different content type.

[cheld]

@deads2k would the second option work for Dashboard, too?

[deads2k]

@deads2k would the second option work for Dashboard, too?

I don't know exactly what the dashboad does, but you can take a look here: kubernetes/community#363

[pwittrock]

More broadly, we need to think about what sort of metadata we want for TPRs - e.g. schema / merge keys?

[nikhita]

/kind feature

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[fejta-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten
/remove-lifecycle stale

[fejta-bot]

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close