fix: create the new http route for setHeaderRoute

[tangzhen]

Based on the documentation of argo-rollouts and gateway-api-plugin:

  ...
  - setHeaderRoute:
      # Name of the route that will be created by argo rollouts this must also be configured
      # in spec.strategy.canary.trafficRouting.managedRoutes
      name: 'argo-rollouts-canary-http-route'
  ...
        # This is a list of routes that Argo Rollouts has the rights to manage it is currently only required for
        # setMirrorRoute and setHeaderRoute. The order of managedRoutes array also sets the precedence of the route
        # in the traffic router. Argo Rollouts will place these routes in the order specified above any routes already
        # defined in the used traffic router if something exists. The names here must match the names from the
        # setHeaderRoute and setMirrorRoute steps.
        managedRoutes:
          - name: argo-rollouts-canary-http-route
        plugins:
          argoproj-labs/gatewayAPI:
            httpRoutes:
              - name: argo-rollouts-http-route
                useHeaderRoutes: true
            namespace: default

The argo-rollouts-canary-http-route is used during a canary rollout; it will be created and managed by Argo Rollouts. After reviewing the implementation of the gateway-api-plugin, it appears that the plugin does not automatically create an HTTPRoute named argo-rollouts-canary-http-route during the rollout.

The existing code updates the current HTTPRoute argo-rollouts-http-route, which causes issues when the application is synchronized by ArgoCD. During the rollout, the existing HTTPRoute adds the header match condition, but this condition is immediately removed by ArgoCD because the HTTPRoute created by ArgoCD does not include it.

[kostis-codefresh]

What you suggest is a breaking change.

I think also that core Argo Rollouts works that way https://argo-rollouts.readthedocs.io/en/stable/features/traffic-management/#traffic-routing-based-on-a-header-values-for-canary . Or do I miss something and Istio support creates 2 separate routes?

I wouldn't want the plugin to work in a different way that Argo Rollouts core.

I think it is better to fix the documentation to be more clear about what is happening.

You should be able to use the ignore differences feature of Argo CD as already explained here https://argo-rollouts.readthedocs.io/en/stable/features/traffic-management/istio/#integrating-with-gitops

[kostis-codefresh]

I updated the documentation in #153

[tangzhen]

I updated the documentation in #153

Thanks for your clarification. If the plugin is designed to change the existing route instead of creating a new one, I'll close the PR.