Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support queue worker paradigm #438

Open
derekperkins opened this issue Mar 11, 2020 · 6 comments
Open

Support queue worker paradigm #438

derekperkins opened this issue Mar 11, 2020 · 6 comments
Labels
enhancement New feature or request no-issue-activity

Comments

@derekperkins
Copy link
Contributor

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
Copy link
Contributor Author

cc @whizard

@derekperkins
Copy link
Contributor Author

#455 will help with this

@jessesuen jessesuen added the enhancement New feature or request label Aug 24, 2020
@aldor007
Copy link

Hey, any updates regarding this topic?

@github-actions
Copy link
Contributor

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

@kostis-codefresh
Copy link
Member

This can be done today by using

  1. Ability to add ephemeral labels to canary/stable pods #455 (ephemeral labels)
  2. The downward api https://kubernetes.io/docs/concepts/workloads/pods/downward-api/
  3. Any application that can reload its configuration when it changes

I am preparing a detailed guide (using rabbitmq as an example) and I will post it here when ready

@kostis-codefresh
Copy link
Member

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request no-issue-activity
Projects
None yet
Development

No branches or pull requests

4 participants