derekperkins commented 4 years ago

Currently argo-rollouts mainly targets http/grpc services, which is great for that use case. Most companies also have queue driven workers that would benefit from the same type of deployment strategy. Rather than managing the traffic directly like you can with a service / mesh, this would require more integration from the application, but I think it could be handled without major architectural changes to rollouts as is.

My hope would be able to set up a watch on the Rollout object as it progresses through its various states, and configure my application accordingly. For example, if my current replicaset is in the preview state for blue/green, I would expect to be able to watch an annotation or a label on the replicaset itself, or alternatively watch the status field of the core rollout object. While in preview mode, I might set my worker to run as normal, but rollback any database transactions rather than committing them. When promotion happens, my app would see that in the watch and start committing those transactions.

I understand that it might not be as magical as being able to migrate live traffic, I believe it is a common use case that isn't being served today. As is, I could probably hack rollouts to do what I'm suggesting by deploying two services that don't serve any purpose except to be the meta that my app would watch. It just seems like unnecessary churn and ip allocation.

derekperkins commented 4 years ago

cc @whizard

derekperkins commented 4 years ago