Add optional full yaml paths to `kubectl explain` output
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]
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.
@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.
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.
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/staleis applied - After 30d of inactivity since
lifecycle/stalewas applied,lifecycle/rottenis applied - After 30d of inactivity since
lifecycle/rottenwas 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
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/staleis applied - After 30d of inactivity since
lifecycle/stalewas applied,lifecycle/rottenis applied - After 30d of inactivity since
lifecycle/rottenwas 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
/close If there is further development desired please re-open
@mpuckett159: Closing this issue.
In response to this:
/close If there is further development desired please re-open
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.