kubectl describe incorrectly splits acronyms in CRD field names
What happened?
When using kubectl describe on Custom Resources with camelCase field names containing acronyms followed by a lowercase letter, the field names are incorrectly humanized with unwanted spaces. For example, a field named respectPDBs is displayed as "Respect PD Bs" instead of "Respect PDBs".
Spec:
Respect PD Bs: true
What did you expect to happen?
The field name respectPDBs should be displayed as Respect PDBs with the acronym kept together, not split into separate parts.
How can we reproduce it (as minimally and precisely as possible)?
test-patchplan-instance.yaml
apiVersion: example.com/v1
kind: PatchPlan
metadata:
name: test-patchplan
spec:
respectPDBs: true
test-pdb-crd.yaml
apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
name: patchplans.example.com
spec:
group: example.com
versions:
- name: v1
served: true
storage: true
schema:
openAPIV3Schema:
type: object
properties:
spec:
type: object
properties:
respectPDBs:
type: boolean
description: Whether to respect Pod Disruption Budgets
additionalPrinterColumns:
- name: Respect PDBs
type: boolean
jsonPath: .spec.respectPDBs
scope: Namespaced
names:
plural: patchplans
singular: patchplan
kind: PatchPlan
kubectl apply -f test-pdb-crd.yaml
kubectl apply -f test-patchplan-instance.yaml
kubectl describe patchplan test-patchplan | grep Respect
Anything else we need to know?
No response
Kubernetes version
$ kubectl version
# paste output here
Cloud provider
OS version
# On Linux:
$ cat /etc/os-release
# paste output here
$ uname -a
# paste output here
# On Windows:
C:\> wmic os get Caption, Version, BuildNumber, OSArchitecture
# paste output here
Install tools
Container runtime (CRI) and version (if applicable)
Related plugins (CNI, CSI, ...) and versions (if applicable)
There are no sig labels on this issue. Please add an appropriate label by using one of the following commands:
/sig <group-name>/wg <group-name>/committee <group-name>
Please see the group list for a listing of the SIGs, working groups, and committees available.
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.
This issue is currently awaiting triage.
If a SIG or subproject determines this is a relevant issue, they will accept it by applying the triage/accepted label and provide further guidance.
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.
/transfer kubectl
This sounds like a bug to me. /triage accepted /priority backlog
@ardaguclu i have submitted a PR https://github.com/kubernetes/kubernetes/pull/135683
/sig cli