kubectl should suggest next kubectl commands

[erictune]

If I do kubectl describe replicationcontroller/foo, there is a good chance that the next thing I want to do is to see details about the pods created by that replication controller.

Therefore, kubectl should suggest these next steps to me. I'm thinking an output format like this:

$ ./kubectl describe rc/foo
$ ./kubectl describe rc/temp
Name:       temp
Namespace:  default
Image(s):   redis
Selector:   run=temp
Labels:     run=temp
Replicas:   1 current / 1 desired
Pods Status:    1 Running / 0 Waiting / 0 Succeeded / 0 Failed
No volumes.
No events.
...
Suggested Next Commands:
      # List all pods created by this replication controller.
      kubectl get pods -l run=temp
      # Describe a running pod created by this replication controller.
      kubectl get pods temp-d729d
      # Get logs from first container of the last failed pod of this replication controller.
      kubectl logs -p  pods temp-5sj4k

Since we don't use URLs and HATEOAS in kubernetes, and since new users do not understand the conventions by which controllers add labels, it is hard for users to know what to do next. As we get more levels of controllers (Deployment/Rc/Pod, ScheduledJob/Workflow/Job/Pod) and as we get more types of objects created by the same controller (PetSet/{Secret,ConfigMap,RC}), it will become tedious for users to navigate the hierarchy even if they know the right commands.

Other example of this feature:

• Job:
  • show Pods it created
  • show all still running pods
  • show last failed pod (if there was a failure)
• RC:
  • show all pods created by the RC
  • show all
• Service:
  • show all pods matching the selector
• ScheduledJob:
  • show Jobs or Workflows it created
• Workflow:
  • show Jobs it created
• Pod:
  • show logs of its containers
  • show logs of previous invokation (if there has been a failure).
• Deployment:
  • show its RCs (since there are typically only 2 or 3 RCs, maybe show one command for individually listing each RC?

[adohe-zz]

@erictune interesting point. I would like to do more investigate about this new feature.

[erictune]

@AdoHe go ahead and work on it! Let me know if you have questions. I'll assign the issue to myself since I can't assign it to you right now. But the issue is yours to work on!

[erictune]

I can also review any PR you produce, and I'll try to answer questions if you have them. You can leave them on this issue.

[adohe-zz]

@erictune I will starting doing this as soon as possible. For any questions, I will leave them here.

[bgrant0607]

Very similar to #20018

@brendandburns wrote:

I just helped a user debug an OOM problem. It's pretty opaque unless you know what you are looking for.

I think that we should augement kubectl get pods so that we both highlight pods that we know are having problems, and if we know why they are having problems, we should print some tips to make them better.

I replied:

Highlighting is an interesting idea. Or we could add some kind of a PROBLEMS column.

I'd like to keep get output uniform (columnar, single row per resource) and relatively concise.

We can add as much as we like to describe.

In general, we should suggest to users that they follow up a get with describe if problems are flagged.

@bprashanth responded:

Can we flag control the smartness? I find the output type=nodeport dumps out to be mildly annoying

[bprashanth]

@bprashanth responded: Can we flag control the smartness? I find the output type=nodeport dumps out to be mildly annoying

Fwiw that only applied to get pods, describe being verbose is fine IMO

[bgrant0607]

@AdoHe do you still plan to work on this? It may help improve command discoverability.

cc @kubernetes/kubectl @kubernetes/docs

[adohe-zz]

sure, I will look back to my old code, and I think this is a long tailing task, so I am focusing on other higher priority issues.

[smarterclayton]

How does someone learn about get and describe?

Run and expose both are good candidates to describe next steps.

[bgrant0607]

cc @vishh

[bgrant0607]

kploy example: https://www.youtube.com/watch?v=ErrzlDewdVQ&index=12&list=PLosInM-8doqcBy3BirmLM4S_pmox6qTw3

[bgrant0607]

This would be especially useful in the case of an error.

A user reported: But "kubectl edit pod hello-node" always fails with error:

Forbidden: pod updates may not change fields other than `containers[*].image` or `spec.activeDeadlineSeconds`

The error is clear IMO, but the user didn't know how to resolve the problem. They were trying to add a secret. We could have recommended to delete and recreate the pod, or update the controller instead (once we have controllerRef).

[0xmichalis]

/sig cli

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

Prevent issues from auto-closing with an /lifecycle frozen comment.

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

[nikhita]

/remove-lifecycle stale /lifecycle frozen