Add optional full yaml paths to kubectl explain output

[spkane]

What would you like to be added: It would be GREAT if there was a way to get kubectl explain to output the full yaml path for each entry, especially when --recursive is set.

So, output that looks like this today:

  metadata	<ObjectMeta>
    annotations	<map[string]string>
    managedFields	<[]ManagedFieldsEntry>
      apiVersion	<string>
      fieldsType	<string>

might look like this:

  metadata	<ObjectMeta>      [metadata]
    annotations	<map[string]string>      [metadata.annotations]
    managedFields	<[]ManagedFieldsEntry>      [metadata.managedFields]
      apiVersion	<string>      [metadata.managedFields.apiVersion]
      fieldsType	<string>      [metadata.managedFields.apiVersion]

Why is this needed:

In addition to using kubectl explain to find out what a field is for and what type it expects, it could be very useful in determining where in the YAML structure a section belongs. With this change, running something like the following would make it much clearer WHERE the section belongs in the YAML manifest.

$ kubectl explain pod --recursive=true | grep preferredDuringSchedulingIgnoredDuringExecution

        preferredDuringSchedulingIgnoredDuringExecution	<[]PreferredSchedulingTerm>    
  [spec.affinity.nodeAffinity.preferredDuringSchedulingIgnoredDuringExecution]
        preferredDuringSchedulingIgnoredDuringExecution	<[]WeightedPodAffinityTerm>    
  [mspec.affinity.podAffinity.preferredDuringSchedulingIgnoredDuringExecution]
        preferredDuringSchedulingIgnoredDuringExecution	<[]WeightedPodAffinityTerm>    
  [mspec.affinity.podAntiAffinity.preferredDuringSchedulingIgnoredDuringExecution]

[k8s-ci-robot]

This issue is currently awaiting triage.

SIG CLI takes a lead on issue triage for this repo, but any Kubernetes member can accept issues by applying the triage/accepted label.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[spkane]

@eddiezane @soltysh Is this something that seems reasonable? If I have some time I might try and make this happen if there are no general issues with the idea.

[mpuckett159]

I think this might be best suited as a plugin to start out with. I'm a little reluctant to accept this because this would make the output pretty cluttered, and this information is generally available elsewhere. If you're willing to put together a PR for us to look at more directly.

Note, I would expect metadata.managedFields to be metadata.managedFieldEntry[] or something else that denotes it's a list.

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle rotten
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten