Support multiple services to be managed by a rollout

[vadasambar]

I have Service A and B pointing to a Deployment D. I want to convert Deployment D into an Argo Rollout but I cannot because Rollout right now supports only one activeService under blue green strategy.

...
  strategy:
    blueGreen: 
      # activeService specifies the service to update with the new template hash at time of promotion.
      # This field is mandatory for the blueGreen update strategy.
      activeService: rollout-bluegreen-active

https://argoproj.github.io/argo-rollouts/features/bluegreen/

[dwalker-va]

My situation is that many apps support different protocols on different ports and they have different Services for this. When I do a rollout, I would like all of the relevant services to be part of the rollout. (Using Istio).

[jessesuen]

Thanks for the second use-case, I'll expand the scope of this to include the canary strategy.

[argee5285]

@jessesuen : Greetings! Is the feature now available to have multiple services rollout in one deployment? We have a deployment where we have multiple services (external - node port) and internal (cluster-ip), mapped to one deployment. We are looking out at using the argo based rollouts (blue-green) to enable that.

[huikang]

Hi, @jessesuen , I can take over this one as we march to v1.2. Implementation wise, we may update the rollout CRD with the following additional fields:

      activeServices:
      - rollout-bluegreen-active-1
      - rollout-bluegreen-active-2
      previewServices:
      - rollout-bluegreen-preview-1
      - rollout-bluegreen-preview-2

We keep the activeService and previewService for backward compatibility like in multiple virtualServices support. What do you think?

[jessesuen]

While I think the spec you are proposing is ideal, I do want to call out some complications with the implementation.

There is quite a bit of the blue-green code which is currently assuming a single activeService, and the controller is examining the Service as the source of truth to infer what stage it is in during blue-green update. But by switching to a list of services, the source of truth could become inconsistent (e.g. if we crash after updating only some of the services).

I think it is worth trying this approach, but in terms of implementation, and in order to reduce risky changes to the controller, we may have to pick one of the services (e.g. the first one), to act as the primary source of truth, and the rest of the services should always follow that definition.

[lamebear]

To add another use case for this, we have to split our HTTP and gRPC traffic from Traefik to our applications so we can use the h2c scheme on the gRPC traffic (have Linkerd handling mTLS). In order to do that, we have to have separate Service resources with different annotations, or separate TraefikService resources to set the scheme/port. So for all of our deployments that expose gRPC and HTTP, we cannot implement Argo Rollouts as we require multiple services.

[github-actions[bot]]

This issue is stale because it has been open 60 days with no activity.