Respect Gateway lattice-service-name annotation for service naming

[dlutsch]

What type of PR is this?

feature

Which issue does this PR fix:

N/A - No existing issue, but the lattice-service-name annotation on Gateway resources is currently ignored by the controller.

What does this PR do / Why do we need it:

Adds support for application-networking.k8s.aws/lattice-service-name annotation on Gateway resources to control VPC Lattice service naming.

Currently, the controller only respects service-name-override on HTTPRoute objects. This PR enables Gateway-level service naming, which is more semantic (Gateway represents the VPC Lattice service) and important for multi-route scenarios and ephemeral environments.

If an issue # is not available please add repro steps and logs from aws-gateway-controller showing the issue:

Repro:

1. Create Gateway with application-networking.k8s.aws/lattice-service-name: my-service
2. Create HTTPRoute referencing the Gateway
3. VPC Lattice service name is {route-name}-{namespace} instead of my-service

Controller Logs (before fix):

{"msg":"Creating service with service network association for route my-route-routes-my-namespace (networks: [sn-xxx])"}

Results in truncated/duplicated name: my-route-routes-my-namespace

Testing done on this change:

Manual testing on EKS cluster with Gateway API Controller v1.1.6:

• Created Gateway with lattice-service-name: my-service
• Created HTTPRoute referencing Gateway
• Result: VPC Lattice service created with name my-service ✓
• Backward compat: HTTPRoute service-name-override still takes precedence ✓
• Running cluster: Updated existing cluster, existing services unaffected ✓

Before:

aws vpc-lattice list-services --query "items[?contains(name,'my')].name"
["my-route-routes-my-namespace"]

After:

aws vpc-lattice list-services --query "items[?contains(name,'my')].name"
["my-service"]

Automation added to e2e:

No. If accepted, can add integration tests in follow-up PR.

Will this PR introduce any new dependencies?:

No. Uses existing validation functions (k8s.ValidateVPCLatticeServiceName, k8s.NewInvalidServiceNameOverrideError) and Gateway lookup (t.findGateway).

Will this break upgrades or downgrades. Has updating a running cluster been tested?:

No breaking changes. Purely additive:

• Route service-name-override: Continues to work (highest precedence)
• Gateway lattice-service-name: Now works (new fallback)
• Auto-generated names: Still work (final fallback)

Tested on running cluster - existing services unaffected, only new/recreated services use Gateway annotation.

Does this PR introduce any user-facing change?:

Yes

Gateway resources can now use `application-networking.k8s.aws/lattice-service-name` annotation to control VPC Lattice service naming. Annotation precedence: HTTPRoute `service-name-override` > Gateway `lattice-service-name` > auto-generated.

Do all end-to-end tests successfully pass when running make e2e-test?:

Not run. Change is minimal (21 lines), uses existing functions, manually tested. Can run e2e if setup guidance provided.

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

[SinghVikram97]

Hi @dlutsch,
Thank you for your contributions to the controller.

I don't see any lattice-service-name annotation that we currently support. Is this PR adding a new annotation lattice-service-name on the gateway?

[dlutsch]

Thanks for the quick review!

You're right - I was introducing a new annotation name unnecessarily. I've updated the PR to use the existing service-name-override annotation instead.

Annotation precedence:

1. HTTPRoute service-name-override (highest - route-specific override)
2. Gateway service-name-override (new fallback - shared across routes)
3. Auto-generated from route name (default behavior)

This way, the same annotation works on both Gateway and HTTPRoute resources, just with different precedence based on specificity.

[SinghVikram97]

What would be the use case to have service-name-override on gateway? Since actual service is created by HttpRoute.

[dlutsch]

The thought was to have the Gateway-level annotation serve as a default fallback for all routes attached to that Gateway. In our specific case, this is useful for ephemeral environments. We dynamically create PR-specific Gateways with multiple HTTPRoutes. For example..

Without Gateway annotation:

• Gateway: pr-123-gateway
• Route 1: Creates VPC Lattice service auth-route-namespace
• Route 2: Creates VPC Lattice service api-route-namespace
• Route 3: Creates VPC Lattice service admin-route-namespace

Result: 3 separate VPC Lattice services for one ephemeral environment.

With Gateway annotation (service-name-override: pr-123-shared):

• All 3 routes create/share the same VPC Lattice service: pr-123-shared

What im hoping to provide:

1. Consistent naming across all routes in an environment
2. Resource consolidation - one service instead of many
3. DRY - no need to repeat the same annotation on every route
4. Flexibility - individual routes can still override if they need unique naming

Happy to change the approach if you feel there is a better way to tackle this.