# In config/crd/bases/elbv2.k8s.aws_ingressclassparams.yaml (v2.13.2)
spec:
  names:
    kind: IngressClassParams
    listKind: IngressClassParamsList
    plural: ingressclassparams
    singular: ingressclassparams  # ❌ Should be "ingressclassparam"

Problem

This naming inconsistency causes:

1. SingularConflict condition: NamesAccepted: False with reason SingularConflict
2. Convention violation: Kubernetes expects different singular/plural forms (e.g., pod/pods)
3. Unhealthy CRD status: Affects tools that validate CRD health conditions

Evidence from Kubernetes API

When applied, Kubernetes shows the conflict:

$ kubectl get crd ingressclassparams.elbv2.k8s.aws -o jsonpath='{.status.conditions[?(@.type=="NamesAccepted")]}'
{
  "message": "\"ingressclassparams\" is already in use",
  "reason": "SingularConflict",
  "status": "False",
  "type": "NamesAccepted"
}

$ kubectl get crd ingressclassparams.elbv2.k8s.aws -o jsonpath='{.status.acceptedNames.singular}'
ingressclassparam  # ← Kubernetes automatically corrected it

Proposed Fix

spec:
  names:
    kind: IngressClassParams
    listKind: IngressClassParamsList
    plural: ingressclassparams
    singular: ingressclassparam  # ✅ Remove the trailing 's'

Impact Assessment

- ✅ AWS LB Controller: No functional impact - uses typed Go clients (&elbv2api.IngressClassParams{}), not CRD string names
- ✅ kubectl: Both names work - Kubernetes accepts plural and singular forms transparently
- ✅ CRD Health: Resolves SingularConflict and achieves NamesAccepted: True
- ✅ Backward compatibility: Fully maintained - existing resources continue working

Environment

- Version: v2.13.2 (confirmed present in latest release)
- Kubernetes: 1.28+ (EKS tested)

Steps to Reproduce

1. Install AWS Load Balancer Controller v2.13.2
2. Check CRD status: kubectl describe crd ingressclassparams.elbv2.k8s.aws
3. Observe SingularConflict condition with NamesAccepted: False

Additional Context

This issue violates the Kubernetes CRD naming convention where singular and plural should be distinct. Similar issues were
reported in other AWS projects (https://github.com/amazon-archives/aws-service-operator/issues/174) and acknowledged as
unintentional bugs.

The current implementation works functionally but creates an unhealthy CRD status that may affect tooling that validates CRD
 conditions.

Reference: https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#create-a-customr
esourcedefinition