Lack of support for service annotations in nginxproxy

[ryan-dyer-sp]

The new v2 architecture appears to solve a problem I was having; the ability to easily have a single installation of the proxy but manage multiple gateways and utilize different k8s infra based on those GWs.

However, the schema for NginxProxy doesnt appear to support setting the annotations on the Service object which AWS at least utilizes heavily for determining how to configure the various types of LoadBalancers (both with the class k8s-sig method and the AWS LB controller). Can we get some support for setting the annotations in a service as part of the NginxProxy config?

I know the annotations can be added to the Service via the Gateway.spec.infrastructure.annotations as a workaround, but this seems out of place as these also get added to the other resources that are created.

Thanks!

[salonichf5]

Hey @ryan-dyer-sp , thank you for your interest in our project.

Please refer to this documentation to set annotations for nginx deployment, this field needs to be set on the Gateway resource.

Let us know if you have any other questions.

[ryan-dyer-sp]

As I stated, I know about that. However that seems like a workaround more than anything else. This ends up setting these same annotations on all the resources, not just the Service in question, which seems awkward to see Service specific annotations on a deployment, etc.

[sjberman]

Specifying labels/annotations on the Gateway resource is defined in the Gateway API specification here. It is recognized that this is a bit "awkward" as it applies to everything, but this is the way that label/annotation propagation could be standardized in the API for any implementation to support and be conformant.

If we added this into the NginxProxy resource, we now have redundant configuration fields and confusion about which take precedence. Per the doc I linked, we could make our product more aware of resource-specific labels and filter them appropriately, but for now unless there are real configuration problems that arise from this, it's not a priority to do so.

[mpstefan]

I do absolutely agree with the sentiment. I would rather this get fixed in the Gateway API so it doesn't feel like this "workaround," but I'm not sure where on their radar this is. For now, it's an issue with all Gateway API implementations.

If you're interested, you can start the discussion or add to one that might already exist on their repo here: https://github.com/kubernetes-sigs/gateway-api