Question: Motivation behind redefinition+composing over wrapping for Rollout CRD

[glerchundi]

First of all, just found this and I think it's a fantastic idea in the same vein of everything related to ArgoProj! Keep up the good work!

Now the question, I was curious about what was the reasoning behind the current Rollout specification. My main concern is about how do you plan to support/scale to more types as stated in #115. Also, it seems to be unaligned of how other are approaching the same wrapping problem; i.e kubefed with Federated<Kind> and leaving the templates as they actually are and add date to the wrapped type.

Those are separated problems but can also be combined, what about Rollout of a FederatedDeplooyment?

Would love to see what do you all have in mind!

[jessesuen]

A major rationale behind a single Rollout object, was we wanted to provide the same exact experience of the Deployment resource, and expose 100% of its spec & capabilities without any of our own abstractions getting in the way. Basically we wanted the Deployment, filled in with the two "missing" deployment strategies, blue-green & canary. One goal for us was that it would be dead simple for people to migrate from Deployments to Rollouts with only a few line changes of their YAML.

I think kubefed with its FederatedDeployment, FederatedConfigMap, FederatedSecret, FederatedServiceAccount etc... has a very different problem it needs solve, which is they need new "federated" versions of all the basic kubernetes primitives. Notice all of these types are completely different resources and unrelated to each other. It makes sense that they would need to namespace these resources into new "Federated" versions of the resource.

Aside from the Deployment resource, the only other native k8s resources that might need similar advanced deploy strategies are: StatefulSet and DaemonSet. But both of these resources have very different behaviors that would warrant an entirely new resource kind and controller. I don't think a generic approach could handle all three types because the manner in which these resources manage their pods are wildly different.

So while it's conceivable that we would introduce something like a StatefulRollout or DaemonRollout in the future, in all likelihood, these other kinds would need very specific/different implementations to mirror their k8s native counterparts. By that same token, it's hard for me to fathom how the rollout logic could be generalized to CRDs like Knative, FederatedDeployment, because the controller would have no understanding nor the ability to control how these CRDs manage their pods.

[jessesuen]

Answering question from https://github.com/argoproj/argo-rollouts/issues/115:

The examples currently seem to assume that what you're looking rollout is a vanilla Deployment. Are there ways roll out a StatefulSet or Custom Resource (e.g. a Knative service)? Perhaps using kustomize transforms? Or are there plans to support this?

I don't think it is easily solvable in a generic way that would provide the same, K8s-native experience that we are aiming for. It is possible that we could have a StatefulRollout or DaemonRollout in the future that is a mirror of those resource types, but filled in with the "missing" deploy strategies.

CRDs are an entirely different beast. I'm not sure how kustomize transformers would help there.

[glerchundi]

Thanks for the answer @jessesuen, it's crystal clear now. Amazing job you're doing here.

[aweis89]

For a scale-to-zero functionality that is compatible with Argo Rollouts, have a look at KEDA.

IMO Knative shot themselves in the foot a bit by using a single resource to manage both rollouts (canary, blue-green etc.) and scaling in a single resource. As Jesse mentioned, that makes it rather difficult to integrate with other rollout tools such as Argo

[PatrickWolleb]

@jessesuen how would you start with writing a StatefulRollout?

[dudicoco]

@jessesuen how about having the controller apply changes to the statefulset/daemonset resources instead of rewriting the logic for those workloads?

For statefulsets the partitioned rolling updates strategy can be used to control the rollout progression. For daemonsets a pod readiness gate can be used to control the rollout progression.