[rabbitmq-discuss] RabbitMQ Administration API

Fri Jul 18 10:09:49 BST 2008

I forgot to mention that for those who wish to follow the working
group discussions, the JIRA is 233 at jira.amqp.org.

alexis

On Fri, Jul 18, 2008 at 9:52 AM, Alexis Richardson
<alexis.richardson at cohesiveft.com> wrote:
> 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
>>
>>
>