search

kubernetes / kubectl

Issue tracker and mirror of kubectl code
Apache License 2.0
2.89k stars 924 forks source link

Add optional full yaml paths to `kubectl explain` output #1604

Open spkane opened 6 months ago

spkane commented 6 months ago

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 commented 6 months ago

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](https://git.k8s.io/community/contributors/guide/pull-requests.md). If you have questions or suggestions related to my behavior, please file an issue against the [kubernetes-sigs/prow](https://github.com/kubernetes-sigs/prow/issues/new?title=Prow%20issue:) repository.
spkane commented 4 months ago

@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 commented 4 months ago

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 commented 1 month ago

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

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

You can:

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

/lifecycle stale

k8s-triage-robot commented 2 weeks ago

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:

You can:

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

/lifecycle rotten