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

Paring Aragorn / Strider deployments #251

Open
YaphetKG opened this issue Jul 5, 2024 · 0 comments
Open

Paring Aragorn / Strider deployments #251

YaphetKG opened this issue Jul 5, 2024 · 0 comments

Comments

@YaphetKG
Copy link
Collaborator

YaphetKG commented Jul 5, 2024

Currently Aragorn implements async callbacks using celery queues.
Once a async request is sent off to strider , a background worker is issued to listen to a celery queue. When strider calls back it targets that particular queue, and message is transferred using that queue.

We can think of scaling this up with multiple striders and multiple Aragon instances. When thinking in that direction the problem becomes that Aragon replicas would need a shared queue, and even then queue id management becomes a shared concern of all Aragorn , to keep track of which queue belongs to which instance.

Here we can propose having a smaller paired solution where Aragorn and strider are deployed as separate containers in a single pod. This would mean localhost routing between them is possible. And they would be able to communicate by just swapping ports and using localhost. This will guarantee that strider calls the Aragorn instance it initiated it , and vice versa.

  • As a start we could think about restructuring this strictly from deployment perspective, i.e have the aragorn pods a celery and a strider container aswell. Once that is working
  • Then replace celery solution to a more light weight solution now that we have everything basically locally with in a single pod. in the code.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant