mirror of
https://github.com/run-llama/llama_deploy.git
synced 2026-08-24 21:01:26 -04:00
[PR #358] [MERGED] refact: Make topic explicit in message queue API #416
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
📋 Pull Request Information
Original PR: https://github.com/run-llama/llama_deploy/pull/358
Author: @masci
Created: 11/12/2024
Status: ✅ Merged
Merged: 11/13/2024
Merged by: @masci
Base:
main← Head:massi/topic-refact📝 Commits (5)
5d85407Make topic explicit in message queue API13b5d71fix unit testsbe7b147more fixes97c44a0fix quotes in e2e code1997f1ebetter naming📊 Changes
39 files changed (+470 additions, -353 deletions)
View changed files
📝
.pre-commit-config.yaml(+1 -1)📝
e2e_tests/apiserver/test_streaming.py(+1 -2)➕
e2e_tests/message_queues/message_queue_kafka/conftest.py(+103 -0)📝
e2e_tests/message_queues/message_queue_kafka/test_message_queue.py(+20 -21)➕
e2e_tests/message_queues/message_queue_kafka/workflow.py(+12 -0)📝
llama_deploy/apiserver/deployment.py(+4 -6)📝
llama_deploy/client/models/apiserver.py(+14 -18)📝
llama_deploy/client/models/model.py(+1 -1)📝
llama_deploy/control_plane/__init__.py(+3 -2)📝
llama_deploy/control_plane/base.py(+7 -3)➕
llama_deploy/control_plane/config.py(+30 -0)📝
llama_deploy/control_plane/server.py(+58 -94)📝
llama_deploy/deploy/deploy.py(+4 -4)📝
llama_deploy/message_publishers/publisher.py(+11 -6)📝
llama_deploy/message_queues/apache_kafka.py(+26 -19)📝
llama_deploy/message_queues/aws.py(+10 -10)📝
llama_deploy/message_queues/base.py(+7 -15)📝
llama_deploy/message_queues/rabbitmq.py(+10 -9)📝
llama_deploy/message_queues/redis.py(+6 -6)📝
llama_deploy/message_queues/simple.py(+12 -15)...and 19 more files
📄 Description
Apologies for the mega-refactoring, breaking this down into smaller PR would take a week 😛
Fixes #349 for good.
Problem
Message publishers and subcribers assumed the "topic" to listen to was the same as the message type. This works in a single-tenant environment but becomes a problem when the same message queue holds data for multiple control planes and services, causing clashes.
Solution
control_plane_one.my_serviceso that services with the same name attached to different control planes can coexistFollow up
🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.