From 92d358854248405836e0f21afa990edf0dcd84a3 Mon Sep 17 00:00:00 2001 From: Flatnotes Date: Sun, 5 May 2024 20:45:15 +0000 Subject: [PATCH] Autocommit action=MODIFY on file=Follow the RabbitMQ - Plan.md detected --- Follow the RabbitMQ - Plan.md | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-) diff --git a/Follow the RabbitMQ - Plan.md b/Follow the RabbitMQ - Plan.md index 7035fc3..4cc6d7b 100644 --- a/Follow the RabbitMQ - Plan.md +++ b/Follow the RabbitMQ - Plan.md @@ -3,7 +3,6 @@ > What kind of issues we faced with rabbit > Is it a RabbitMQ setup issue or an Openstack issue ? - * Issues with rabbit ? * flap when rolling out agent / deploying new agent version * even crash on big regions @@ -13,7 +12,6 @@ > Which methods did we use to troubleshoot those issues > Observability, tools - * What's going on with rabbit ? * What we deployed to help troubleshooting issues * reproduce workload with rabbit perftest @@ -33,7 +31,6 @@ > Before going further, let's take some time to understand how oslo.messaging work > How RPC is implemented in Openstack > [[ oslo.messaging - How it works with rabbit]] - * Under the hood ? * pub/sub mechanism * subscriber: RPC server topic=name @@ -46,7 +43,6 @@ * notifications for external use: kafka > What we did to put rabbits back to their holes - * Journey to get a stable infra. * Infra improvment * split rabbit-neutron / rabbit-\* @@ -63,4 +59,10 @@ * reduce queue nb a lot * patch to avoid tcp reconnection when a queue is deleted (kombu/oslo) * reduce queues declared by a RPC server (3 queues by default to only 1) - * use same connection for mutiple topics \ No newline at end of file + * use same connection for mutiple topics + +> ... +- Conclusion + - when rabbitmq is used for what it is designed for, it works better + - going further ? + - let's write an oslo.messaging driver for another backend ? \ No newline at end of file