[rabbitmq-discuss] RabbitMQ Administration API

Fri Jul 18 09:52:44 BST 2008

Edwin

I am going to topline this.  Apologies.

First of all, I agree with John that a general schema based approach
has genuine appeal, for example it can be applied to use AMQP as a
proxy service to manage other classes of objects via queues.  That's
quite cool, and makes AMQP more useful in the general context of
management and monitoring which is in itself an important use case.

Second, when discussing 'management' in the AMQP Working Group, we
found that management of an AMQP broker or cluster is context
dependent.  It means different things to different people.  For
network operations and administration folks, it means a set of
standard packet sniffing tools and management protocols.  For
application developers, it means platform integration eg JMX.  And
this is just if you assume that people will manage AMQP brokers as
they manage other servers.  But this assumption is not true - new
modes of management may be required, for example to propagate change
transactionally.

In such a case-based setting my preference would be to go with a
bottom-up approach based on Things That Already Work And Which We Use.
 Making use of the rich tooling and management capability provided by
erlang/OTP is a really good thing to do, and SNMP is completely
essentially to many people.  So I am all in favour of the sort of
approach Edwin has taken, and that he now proposes.

What do other people think?

alexis

On Thu, Jul 17, 2008 at 4:51 PM, Edwin Fine
<rabbitmq-discuss_efine at usa.net> wrote:
> John,
>
> Thanks for the reference to the earlier discussion. I missed that one. I am
> also influenced to some degree by what MQ did for its admin control.
>
> I'd like to contrast my approach with the QPID one.
>
> My approach was extremely pragmatic and bottom-up. It did not try to solve
> all the problems and create a grand design. The QPID approach is at the
> opposite end of the spectrum. Both approaches have merits and shortcomings.
> Mine is very limited and short-sighted, but has the advantage of being very
> easy to understand, and immediately available to play with and get a feel
> for what is wanted and needed. The QPID approach would take a great deal
> more work, and testing, just to get something usable on RabbitMQ. This
> impedes progress. I have always been a proponent of eliciting realistic
> requirements by prototyping (as long as the prototype does not suddenly
> become the production version, which is always a danger). It grounds us in
> practicalities right from the start. Once we see what actually works, we do
> another iteration to expand the design to become more generic. Another
> disadvantage is that we may not think of a very important feature until late
> in the game, and have to change the entire architecture. That's why it's
> best to get high-level requirements up front, in a timeboxed fashion to
> prevent analysis paralysis, and then try the various features out for
> real-world usability, and iterate until cooked.
>
> QPID's approach is interesting in that it uses the AMQP protocol itself as
> the communication mechanism. I quite like this idea from the point of view
> that every AMQP language binding will be able to use it. On the other hand,
> it's a bit clumsy and heavyweight in that you have to set up one or more
> private queues just to talk the the management broker, and as far as I can
> see, it's very generic, so I am uncertain of exactly what capabilities are
> exposed (e.g. how do you delete a queue?).
>
> The major QPID concepts seem to be:
>
> Defining the concept of a flexible schema structure
> Querying object information
> Setting up monitoring
> Calling object methods
> Defining the communication protocol
>
> It suddenly struck me as I was writing this that there is already a very
> well defined standard that does all this, which is SNMP. Since SNMP is a
> widely-used standard, and Erlang supports it, and SNMP v3 has security
> features built in, and SNMP allows one to monitor, configure and control any
> arbitrary object, shouldn't we consider adding an SNMP agent to RabbitMQ,
> and using SNMP for all these tasks?
>
> The huge advantage of this is that it makes a RabbitMQ node automatically
> become part of any SNMP management infrastructure. There are many existing
> SNMP Management tools, and a lot of information and books on SNMP. Another
> huge advantage is it would not be reinventing the wheel. The disadvantage is
> that it is orthogonal to AMQP, but maybe that's not such a bad thing.
>
> The task then becomes mostly one of defining appropriate MIBs that can
> describe, monitor and control an AMQP infrastructure.
>
> Thoughts? Am I missing something?
>
> Regards,
> Edwin Fine
> On Thu, Jul 17, 2008 at 9:27 AM, John Watson <JWatson at sis.tv> wrote:
>>
>> When this was discussed earlier on the rabbit forum:-
>> http://www.trapexit.org/forum/viewtopic.php?p=37702 I thought that one of
>> the most interesting responses described the approach taken by QPID:
>> http://cwiki.apache.org/qpid/management-design-notes.html .
>>
>>
>>
>> Cheers
>>
>> John Watson
>>
>> **********************************************************************
>>
>> Satellite Information Services Limited Registered Office:
>>
>> 17 Corsham Street London N1 6DR, Company No. 4243307
>>
>>
>>
>> The information in this e-mail (which includes any files
>>
>> transmitted with it) is confidential and is intended for the
>>
>> addressee only. Unauthorised recipients are required to
>>
>> maintain confidentiality. If you have received this e-mail
>>
>> in error please notify the sender immediately, destroy any
>>
>> copies and delete it from your computer system.
>>
>> **********************************************************************
>>
>>
>
>
> --
> 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)
> _______________________________________________
> rabbitmq-discuss mailing list
> rabbitmq-discuss at lists.rabbitmq.com
> http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
>
>