Feature Request: Support Multiple Workload References in a Single Rollout

[schnell3526]

Hey Argo Rollouts team 👋

First off, thank you for building such an incredible project! We've been using Argo Rollouts in production for progressive delivery, and it's been a game-changer for our deployment safety.

I'm reaching out because we've hit an interesting challenge that I think many organizations face - managing cost-optimized infrastructure while maintaining deployment safety.

Our Challenge

We run the same application across two infrastructure tiers:

• Base tier: On-demand instances for Reserved Instance utilization and guaranteed capacity
• Scale tier: Spot instances for cost-effective burst capacity

Both tiers run identical application code and must stay on the same version, but they differ only in Kubernetes scheduling constraints (node affinity, tolerations, etc.). Currently, we use separate Deployments to achieve this infrastructure separation, which creates a coordination problem during rollouts.

We've been working around this with operational constraints (deploying during low-traffic periods, manually checking Scale tier pod counts), but this adds operational burden without truly solving the problem.

---

Feature Request: Support Multiple Workload References in a Single Rollout

Summary

Add support for managing multiple Deployments with a single Rollout, enabling coordinated progressive delivery for workloads that share the same application but differ in infrastructure configuration.

Proposed Solution

API Extension

Introduce workloadRefs (plural) alongside existing workloadRef.

# Existing (unchanged)
spec:
  workloadRef:
    kind: Deployment
    name: app

# New
spec:
  workloadRefs:
    - kind: Deployment
      name: app-base
    - kind: Deployment
      name: app-scale

Behavior

All referenced Deployments:

• Deploy to the same version simultaneously
• Share the same rollouts-pod-template-hash
• Participate in the same Blue-Green/Canary deployment
• Roll back together if Analysis fails

Validation Rules

• workloadRef and workloadRefs are mutually exclusive
• All referenced Deployments must have compatible Pod template structure (same containers, potentially differing in scheduling constraints only)

Backward Compatibility

This proposal is fully backward compatible:

• Existing workloadRef continues to work unchanged
• workloadRefs is purely additive
• No migration required

This pattern follows Kubernetes API evolution conventions (similar to container → containers).

Distinction from Related Issues

Issue	Scope	Key Difference
#451	Multiple Services → Single Deployment	Service-side expansion
#2088	Multiple independent Rollouts coordination	Orchestration across different applications
#2737	Multi-cluster Rollout synchronization	Cross-cluster coordination
#2912	Keep worker Deployment in sync	Background worker, not serving traffic

This proposal is fundamentally different - it addresses a single application deployed across infrastructure tiers. Since the application layer is identical:

• The complexities raised in Support multi-rollout promotion process #2088 (partial rollback, inter-rollout dependencies) don't apply
• All Deployments roll back atomically as a single unit

This aligns with how Kubernetes Service uses label selectors to abstract over multiple Pods. We're proposing Rollout abstract over multiple Deployments of the same application.

Implementation

If this proposal aligns with the project's direction, I would like to take ownership of the implementation.

Proposed approach:

• Initial implementation (Beta): Validation-based approach that rejects Deployments with incompatible Pod templates
• Future iteration: Fallback strategies for configuration drift (separate proposal based on feedback)

I'm prepared to create a detailed design document and implement a proof-of-concept once we align on the approach.

Thanks for taking the time to read this! 🙏