HTTPProxy status update fails with "ports[].error: Required value" when using AWS NLB

[joelp172]

Description

When using Contour with an AWS Network Load Balancer, the HTTPProxy status cannot be updated because the CRD schema marks the error field as required in status.loadBalancer.ingress[].ports[]. However, Contour doesn't set this field when there's no error, causing validation to fail.

Environment

Contour version: v1.33.1
Helm chart version: 0.2.1
Kubernetes version: 1.35
Cloud provider: AWS (EKS)
Load balancer type: NLB

Steps to Reproduce

1. Deploy Contour with an AWS NLB service
2. Create an HTTPProxy resource
3. Check Contour logs for status update errors

Expected Behavior

HTTPProxy status.loadBalancer should be populated with the NLB hostname, allowing external-dns and other controllers to read the address.

Actual Behaviour

Contour logs show:

level=error msg="unable to update status" context=StatusUpdateHandler error="HTTPProxy.projectcontour.io \"contour-test-app\" is invalid: [status.loadBalancer.ingress[0].ports[0].error: Required value, status.loadBalancer.ingress[0].ports[1].error: Required value, <nil>: Invalid value: null: some validation rules were not checked because the object was invalid; correct the existing errors to complete validation]" kind=HTTPProxy name=contour-test-app namespace=contour-system

The HTTPProxy status shows:

status:
  loadBalancer: {}  # Empty - never populated

Root Cause

The HTTPProxy CRD schema has error marked as required:

{
  "required": ["error", "port", "protocol"]
}

Path: spec.versions[0].schema.openAPIV3Schema.properties.status.properties.loadBalancer.properties.ingress.items.properties.ports.items.required

The error field should be optional - it's only needed when there's an actual error to report.

Workaround

Patch the CRD to make error optional:

kubectl patch crd httpproxies.projectcontour.io --type=json -p='[
  {
    "op": "replace",
    "path": "/spec/versions/0/schema/openAPIV3Schema/properties/status/properties/loadBalancer/properties/ingress/items/properties/ports/items/required",
    "value": ["port", "protocol"]
  }
]'

Suggested Fix

In the HTTPProxy CRD definition, change the required fields for ports.items from:

required:
  - error
  - port
  - protocol

To:

required:
  - port
  - protocol

Impact

• HTTPProxy resources don't get their status.loadBalancer populated
• external-dns cannot create DNS records for HTTPProxy resources
• Any tooling that relies on HTTPProxy status is broken

Additional Context

This issue appears to affect NLB services specifically because they include ports in the LoadBalancer status. Classic ELBs or ALBs may not trigger this issue if they don't include port information.
The standard Kubernetes Ingress resource is unaffected - only HTTPProxy has this validation issue.

[github-actions]

Hey @joelp172! Thanks for opening your first issue. We appreciate your contribution and welcome you to our community! We are glad to have you here and to have your input on Contour. You can also join us on our mailing list and in our channel in the Kubernetes Slack Workspace

[tsaarni]

Thank you for the report @joelp172!

The CRD is generated from the Go code (link), not manually written.

Contour defines HTTProxy.status.loadBalancer by reusing the Kubernetes API type core_v1.LoadBalancerStatus. This type contains the PortStatus struct, which has conflicting markers: +optional but +kubebuilder:validation:Required. After Controller-tools v0.16.x (included in Contour v1.31.0) this conflict has caused the error field to be marked as required in the generated CRD. The issue was also mentioned in kubernetes-sigs/controller-tools#944 (comment). The suggested fix was to remove the +kubebuilder:validation:Required marker from the Kubernetes API, but this did not happen possibly due to backwards compatibility concerns. For example, it remains here in kube-api-linter excemption file.

Alternative solutions on Contour side could include:

1. Replace core_v1.LoadBalancerStatus with a custom type (breaks Contour's Go API package compatibility)
2. Modify the generated CRD before release (similarly as you did in workaround, potentially error prone)
3. Treat error field as required and set it to an empty string when absent (could confuse clients that expect no error field in success case)