[rabbitmq-discuss] RabbitMQ Administration API
John Watson
JWatson at sis.tv
Fri Jul 18 10:11:18 BST 2008
Hi, Alexis,
What I really need is something akin to MQSC -
http://publib.boulder.ibm.com/infocenter/wmqv6/v6r0/index.jsp?topic=/com
.ibm.mq.csqzaj.doc/sc10340_.htm . My main Use Case is to be able
(eventually) to configure a network of autonomous rabbit nodes with
appropriate objects using some sort of scripting language, and to be
able to automatically generate, deploy and execute the scripts. I am not
going to make much use of dynamic changes - most of the networks I set
up have a reasonably static topology with the main change being the
setting up of new customers with appropriate content-based-routing
rules.
I tend to use SNMP just for monitoring a running network.
John
-----Original Message-----
From: alexis.richardson at gmail.com [mailto:alexis.richardson at gmail.com]
On Behalf Of Alexis Richardson
Sent: 18 July 2008 09:53
To: Edwin Fine
Cc: John Watson; rabbitmq
Subject: Re: [rabbitmq-discuss] RabbitMQ Administration API
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
**********************************************************************
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.
**********************************************************************
More information about the rabbitmq-discuss
mailing list