How Argo Rollouts fits into a large system with many existing deployment YAMLs

[morningspace]

Hi team, Argo Rollouts is great but I have a question when I was trying to apply Argo Rollouts to my project where there are many modules with deployment YAMLs already exist. According to the docs, it looks it uses Rollout resources wrapped with workloads in form of image containers to support the progressive delivery. (Similar to the Kubernetes native resource Deployment). Does it mean I have to transform all my modules deployment YAMLs from Deployment, Job, DaemonSet, etc. into Rollout? If that's the case, it will be a huge effort.

More specifically, our project is organized using Operator Lifecycle Manager (OLM), where all workloads are actually implemented as operators and deployed using OLM. Typically, this requires all operators to define their references to container images in cluster service version(CSV) with corresponding image tag or digest then bundled into a CatalogSource resource. In such a case, when I consider patching a code fix to a live system using Argo Rollouts, I'm not sure how to do it. It is the CSV resource which includes the reference to the image and I cannot change it to Rollouts because it won't be recognized by OLM.

Any suggestion? Or did I miss something?

[nextrevision]

As you mention, you can use the Rollout CRD instead of a Deployment, however, new to v1.0.0 is the ability for Rollouts to reference a Deployment type. Not sure if this would be helpful in reducing your refactor cost with adopting rollouts: https://argoproj.github.io/argo-rollouts/migrating/#convert-deployment-to-rollout

[morningspace]

@nextrevision Yeah, that seems to be a great idea! With that, I guess I can just make some additions, the Rollouts, to my existing project rather than modify the existing Deployments in my project directly. I will give it a try. Thanks!