Application-gateway-kubernetes-ingress: Break in the event of unresolved backend causes incomplete backend deployment

[Joon]

When the backends are resolved to http settings, there is code to log an unresolved back-end. Currently, this code also then stops processing the list.

The problem is that when the backends have working and unresolved ones mixed together, working backends after the unresolved one are not provisioned.

Example, K8s has the following ingresses

• Ingress 1 (backend resolved)
• Ingress 2 (backend resolved)
• Ingress 3 (backend unresolved)
• Ingress 4 (backend resolved)

Current behavior:
The following backends are provisioned:

• Default backend
• Ingress 1 Backend
• Ingress 2 Backend

Listeners for Ingress 3 and Ingress 4 are provisioned connected to the default backend.

Expected behavior:
Ingress 4 should have its backend provisioned, and the listener for Ingress 4 should be pointed to that backend

Expected fix:
It looks like removing the break statement on this line should fix the issue:
https://github.com/Azure/application-gateway-kubernetes-ingress/blob/b1d68f1e693a07f3231915e713f5583d0877f439/pkg/appgw/backendhttpsettings.go#L148

The subsequent block of code should only execute when the nr of resolved ports is greater than 0

[akshaysngupta]

@Joon thanks for reporting. We have seen this issue before.
cc: @3quanfeng

[andredewes]

@akshaysngupta @3quanfeng Any plans when this will be fixed? At my company we're evaluating AGIC instead of NGINX as ingress controller and found out the same issue: if one of the backends cannot be resolved, AGIC just wipes out the other working backends previously in Application Gateway. This is really a stopping issue since someone can make a small mistake in the ingresses and studently all your routes are broken.

[akshaysngupta]

We have addressed bug related to break statement in 1.4.0. Please give that a try.