-
Notifications
You must be signed in to change notification settings - Fork 176
RabbitMQ
[IN PROGRESS][IN PROGRESS][IN PROGRESS][IN PROGRESS][IN PROGRESS]
On the use of messaging services (i.e. RabbitMQ)
- Authors: Federico Stagni, Zoltan Mathe, Wojciech Ian Kremzien, ...
Messaging systems like RabbitMQ can be useful for performing several tasks in DIRAC. This RFC is created for discussing use cases, and for integration within the DIRAC framework.
RFC 21 on the Evolution of Transformation System already gives an example of a possible use case. The idea is to achieve data driven through usage of MQ like RabbitMQ. Details are in the RFC.
RabbitMQ is the market's leader when coming to interactions with monitoring tools.
DIRAC does not provide, at the moment, a pilots logging system. Authors think that such system could be provided using a message queuing system. RabbitMQ appears to be the most suitable candidate.
Executors work in a similar fashion to MQ systems. It should be studied if MQs can do the same job, but better.
From now on, we use RabbitMQ's jargon, and we consider specifically the case of integration of RabbitMQ within the DIRAC framework.
RabbitMQ has a server and a client part. The server part is host of the queues, the client part is for sending (RMQ Producers) and receiving (RMQ Consumers) messages to the queues inside the servers. Accessing queues can be assimilated to accessing databases (or, better, accessing services that expose database functionalities). RMQ producers are clients, while RMQ Consumers can be considered, in DIRAC jargon, like any other DIRAC component (e.g. like agents, or better like executors).
The CS can be used for storing access info to RMQ queues. The following locations are advised:
/DIRAC/Systems/[System]/[Setup]/MessageQueueing/[QueueName]/User /DIRAC/Systems/[System]/[Setup]/MessageQueueing/[QueueName]/Host /DIRAC/Systems/[System]/[Setup]/MessageQueueing/[QueueName]/...
And
/LocalInstallation/MessageQueueing/Password
On the local cfg where DIRAC is running.
These locations are mimicking the locations that we use today for MySQL DBs and we believe that they can be enough on a first approximation.
We'll also need to create a "MessageQueueing" utility as we have a "DB" utility, and maybe a "RabbitMQ" utility as we have a "MySQL" utility. We should also see if and how to add the installation of RabbitMQ servers to InstallTools, and of course we'll need it in the Externals.
Within the LHCbDIRAC extension of InstallTools, we already added the "consumer" component type (http://svnweb.cern.ch/world/wsvn/dirac/LHCbDIRAC/trunk/LHCbDIRAC/Core/Utilities/InstallTools.py). This can be easily backported, clearly.
Consumers can be run like any other component, so we can run/control them with runsv. But, if we don't define a "dirac-consumer" script encapsulating the consumers, then we won't be able to pass them options. So, we should create a "ConsumerModule" utility (similar to the "AgentModule") where we can add basic things like monitoring. We should also add a "dirac-consumer" script similar to what we have for "dirac-agent" or "dirac-service" script.
Clients should be able to put/get into RMQ queues by using username/password (this is the case for servers) but also using certificates or RFC proxies.
The implementation of RMQ is such that we need to register in its configuration the DNs of the users allowed to commit.
One of RabbitMQ’s supported plugins maps X.509 DNs to usernames: https://github.com/rabbitmq/rabbitmq-auth-mechanism-ssl RabbitMQ allows fine grained access control at the level of individual users, exchanges, and queues: http://www.rabbitmq.com/access-control.html
Then it's just finding if you can add the credentials of the user to the message.
f that plugin accepts proxies AND you can force something to be added to the message based on the DN+ip (for instance) then it's fine. That way we can prove origin of messages and react accordingly.
RabbitMQ uses OpenSSL for its TLS support, and you can turn on OpenSSL support for RFC proxies with an environment variable.