[rabbitmq-discuss] Management plugin preview release

[Dave Greggory]

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

Sounds good.



>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 
>
>working, so 
>
>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 
production system.

>> 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 
>this
>> 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 
security.