fix(trafficrouting): Fix setHeaderRoute behavior to affect only related ingress rules

[ArenSH]

This PR fixes ALB::SetHeaderRoute so it only affects Ingress rules that contain stableService as backend.

For example, if we have some ingress:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: some-ingress
  annotations:
    alb.ingress.kubernetes.io/actions.redirect-to-app: 'some action'
    # ...
spec:
  defaultBackend:
    service:
      name: svc-stable
      port:
        name: some-port
  rules:
  - host: host1.example.local
    http:
      paths:
      - backend:
          service:
            name: redirect-to-app
            port:
              name: use-annotation
        path: /
        pathType: ImplementationSpecific
  - host: host2.example.local
    http:
      paths:
      - backend:
          service:
            name: redirect-to-app
            port:
              name: use-annotation
        path: /
        pathType: ImplementationSpecific
  - http:
      paths:
      - backend:
          service:
            name: svc-stable
            port:
              name: use-annotation
        path: /*
        pathType: ImplementationSpecific

And rollout with the following step:

#...
  strategy:
    canary:
      stableService: svc-stable
      canaryService: svc-canary
      steps:
      - setWeight: 10
      - setHeaderRoute:
          match:
          - headerName: x-user-agent
            headerValue:
              exact: test-framework
          name: route-test-requests
# ...

Then, without this fix, the new route-test-requests path will be added to every rule in Ingress. Documentation leaves impression that only rules related to rollout services will be affected.

I'm not sure this fix is consistent with desired argo-rollouts behavior, sou would be happy to receive feedback and adjust the code.

Checklist:

• Either (a) I've created an enhancement proposal and discussed it with the community, (b) this is a bug fix, or (c) this is a chore.
• The title of the PR is (a) conventional with a list of types and scopes found here, (b) states what changed, and (c) suffixes the related issues number. E.g. "fix(controller): Updates such and such. Fixes #1234".
• I've signed my commits with DCO
• I have written unit and/or e2e tests for my change. PRs without these are unlikely to be merged.
• My builds are green. Try syncing with master if they are not.
• My organization is added to USERS.md.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 83.89%. Comparing base (b8a9bf5) to head (41cfaeb).

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #3727      +/-   ##
==========================================
+ Coverage   83.88%   83.89%   +0.01%     
==========================================
  Files         163      163              
  Lines       18560    18563       +3     
==========================================
+ Hits        15569    15574       +5     
+ Misses       2119     2118       -1     
+ Partials      872      871       -1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[github-actions]

Published E2E Test Results

  4 files    4 suites   3h 13m 53s ⏱️
113 tests 104 ✅  7 💤 2 ❌
456 runs  424 ✅ 28 💤 4 ❌

For more details on these failures, see this check.

Results for commit 41cfaeb.

♻️ This comment has been updated with latest results.

[github-actions]

Published Unit Test Results

2 276 tests   2 276 ✅  2m 59s ⏱️
  128 suites      0 💤
    1 files        0 ❌

Results for commit 41cfaeb.

♻️ This comment has been updated with latest results.

[sonarcloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
21.5% Duplication on New Code

See analysis details on SonarCloud

[zachaller]

With this PR does this mean that with set heady it will not send 100% of traffic with the configured header to the canary?

[ArenSH]

With this PR does this mean that with set heady it will not send 100% of traffic with the configured header to the canary?

Sorry for delayed response. I'm not sure I understand the case correctly. The getTrafficForwardActionString is not affected and it sets 100% weight to canary for matching header. So the annotation works as expected.

The problem this fix addresses is that Ingress might contain additional rules (like redirects in example) and they are also affected (the generated Path is prepended there too) by setHeaderRoute.

With this fix, the generated Path is only prepended to rules that target stable service. And, if I'm not mistaken, Ingress should not contain explicit rules that route traffic to canary - that is argo-rollouts job. So any other rules remain untouched.