[rabbitmq-discuss] Management plugin preview release
davegreggory at yahoo.com
Mon Sep 13 15:28:59 BST 2010
Sending to list...
----- Forwarded Message ----
From: Dave Greggory <davegreggory at yahoo.com>
To: Simon MacMullen <simon at rabbitmq.com>
Sent: Mon, September 13, 2010 10:19:20 AM
Subject: Re: [rabbitmq-discuss] Management plugin preview release
>Ultimately I see the management plugin replacing the status plugin. However the
>status plugin is pretty simple and it's hardly taking any of our time to keep it
>I imagine that state of affairs could persist for quite a while. I doubt it'll
>see any development though.
If we can keep the Status plugin around until Management plugin comes out of
beta, that should be good enough for us. I realize Status plugin is also beta,
but we're comfortable with it for now (as opposed to not having any monitoring
at all), but I'd hate to have to put another beta plugin out there on a
>> 5. Ability to isolate plugin failures from taking down RabbitMQ - (ie run the
>> plugin on a single RAM node in a cluster that no apps connect to, but from
>> node monitor the status of other nodes in the cluster)
>At the moment the management plugin isn't very sensible in the context of
>clustering, but that will get fixed.
To be explicit, you're saying that you plan to have some way to have the
Management plugin show the state of nodes in the cluster other than the one it's
running on? I much rather prefer this approach because that way, we can have a
node in the cluster that isn't really used for messaging, but solely to monitor
other nodes in the cluster that do the actual work.
>I would hope the plugin should not be capable of taking down Rabbit though. If
>it ever does I most certainly want to hear about it!
Yep, but it'd be nice if we can pre-empt that possibility even for situtations
you/we haven't come across yet :)
>> 6. Configurable permissions to lock down what can be done through the plugin
>The short-term plan is to add a superuser bit to define whether users can
>manipulate non-AMQP objects (users / vhosts / permissions) at all. For AMQP
>objects the >existing permission system is used. Would this be adequate?
Yep taking away access from users/vhosts/permissions should suffice in terms of
More information about the rabbitmq-discuss