[rabbitmq-discuss] RabbitMQ Administration API

[Edwin Fine]

I've spoken to Ben about this topic in the past, and he advised me to open
an new topic on it, which is what I'm doing.

In the MQ world (IIRC) there is an administration API through which one can
do virtually anything that one can do using the command runmqsc. I believe
that RabbitMQ really, really needs something similar. When I could not
figure out how to delete a no-longer needed permanent queue using
rabbitmqctl, I wrote a simple Erlang module (source code attached), which I
named rbmq_admin, that makes available a number of administrative RabbitMQ
commands.

This exports the following Erlang functions:

stop/1, stop_app/1, start_app/1, reset/1, force_reset/1, cluster/2,
status/1, add_user/3,
delete_user/2, change_password/3, list_users/1, add_vhost/2, delete_vhost/2,
list_vhosts/1,
map_user_vhost/3, unmap_user_vhost/3, list_user_vhosts/2,
list_vhost_users/2, add_realm/3,
delete_realm/3, list_realms/2, set_permissions/5, list_permissions/3,
list_queues/1, delete_queue/3,
permission_list/1

With these, I can do just about anything I need to administer RabbitMQ. It
uses rpc:call() to communicate with the Rabbit node, so it's usable across
nodes, subject to Erlang features like cookies and -sname/-name usage. I use
it to create realms, vhosts, users, and so on using Erlang. I even wrote a
simple Yaws web page that lists all the queues on a given node and vhost,
together with how many messages are outstanding on the queue and how many
consumers are attached. With the wrapper, it's fairly trivial to do.

Now the weakness of this approach is that these commands are really just a
thin wrapper over functions exported by the following RabbitMQ modules:

rabbit, rabbit_mnesia, rabbit_access_control, rabbit_realm, and
rabbit_amqqueue.

This has the following shortcomings:

   1. It is intimately tied to rabbit internal APIs. Any change to the APIs,
   even just for the sake of refactoring, will break this.
   2. It uses internal formats (e.g. tuples) returned by the API, which also
   tightly couples it to the internals.
   3. It is non-standard.
   4. It's only available in Erlang.

For me, these are not huge issues right now (until they change the internals
:). However, if there is to be a standard RabbitMQ Admin API, Ben and his
colleagues will need to implement it and release it officially. We can help
by defining what we would like to see in it.

What this topic hopes to achieve is to (a) gauge the interest in the
RabbitMQ community for something like this, and (b) if there is enough
interest, gather requirements -- or even just a wish list -- from the
community. The wrapper I wrote and this post could be a starting point for
this discussion.

The API would require at least the following:

   1. It would need to be available in multiple languages, to support the
   multiple clients (e.g. Java, .NET, Erlang). Hopefully it could be defined in
   such a way that one language-agnostic manual could be written for all the
   languages, together with short language-specific chapters to clarify exact
   usage for that language binding.
   2. The formats of data passed to and returned from the API would have to
   become cast in concrete. For example, at the moment a list of queues
   returned by rabbit_amqqueue:stat_all/0 is in this format:
   [{ok,{resource,<<"resource name">>,queue,<<"queue name">>},
   NumMsgs,NumConsumers},...]. A canonical format for this (and all the
   others) needs to be defined, which won't change (or can change in a
   non-breaking way), even if there are internal RabbitMQ changes. Preferably,
   the data formats should be extensible so that new data points can easily be
   added that will not break existing code. How to do this across multiple
   languages is a good question, unless a language-agnostic format such as XML
   (heavy) or JSON (haven't used it) or something similar is used. I expect
   there will be much debate about this.
   3. It would need to be powerful enough to do most or all administrative
   tasks. Again, the list of functions above could be a starting point.

I hope this is of interest.

Regards,
Edwin Fine

On Wed, Jul 16, 2008 at 6:55 AM, Ben Hood <0x6e6562 at gmail.com> wrote:

> Michael,
>
> On Wed, Jul 16, 2008 at 10:44 AM, Tony Garnock-Jones <tonyg at lshift.net>
> wrote:
> > Hi Michael,
> >
> > Michael Arnoldus wrote:
> >> Speaking of which - if it should happen that I one late night are
> >> finding myself sorely missing working in erlang to the degree that I'd
> >> like to experiment with this - do you have any docs or just pointers to
> >> how to receive and send AMQP from inside erlang? I guess using the
> >> erlang AMQP client to let the server talk to itself isn't exactly the
> >> right approach ...
>
> Can you elaborate on why using the Erlang client to let the *server
> speak to itself* may the wrong approach?
>
> As Tony has pointed out in the previous post, you can use the internal
> rabbit API to send and receive messages, but this means that you tie
> yourself in the internals of Rabbit, which *may* change over time.
>
> HTH,
>
> Ben
>
> _______________________________________________
> rabbitmq-discuss mailing list
> rabbitmq-discuss at lists.rabbitmq.com
> http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
>
>


-- 
The great enemy of the truth is very often not the lie -- deliberate,
contrived and dishonest, but the myth, persistent, persuasive, and
unrealistic. Belief in myths allows the comfort of opinion without the
discomfort of thought.
John F. Kennedy 35th president of US 1961-1963 (1917 - 1963)



-- 
The great enemy of the truth is very often not the lie -- deliberate,
contrived and dishonest, but the myth, persistent, persuasive, and
unrealistic. Belief in myths allows the comfort of opinion without the
discomfort of thought.
John F. Kennedy 35th president of US 1961-1963 (1917 - 1963)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20080716/11e7f0c8/attachment.htm 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rbmq_admin.erl
Type: application/octet-stream
Size: 6922 bytes
Desc: not available
Url : http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20080716/11e7f0c8/attachment.obj