QMF: managing large numbers of nodes

[Sam Joyce <sj...@redhat.com>]

Hi Folks,
I'm new to the list and I'm coming to grips with QMF at the moment and 
have a thought that may be of interest. I was talking with some folks 
last week about managing large numbers of nodes; cloud/grid where there 
are typically thousands of managed elements.
In some cases, e.g. purging a queue, there may be application level 
logic as to which queues need to be purged and when. using the existing 
QMF tooling this would be fairly time consuming from a sysadmin 
perspective.
Don't get me wrong, I like the current interface and its in keeping with 
the tooling for most other message based admin systems that I've used.
So, an idea for discussion: what if managed elements could "subscribe" 
for certain management events. In a large scale deployment, the sysadmin 
wouldn't need to know which nodes to manage explicitly and would instead 
"publish" a management event, like "purge backout queues for app X"
I know my use of "publish" and "subscribe" isn't quite correct in qpid 
terms, but I hope you get the idea.
thoughts?
regards,
Sam.

---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org

Re: QMF: managing large numbers of nodes

[Rafael Schloming <ra...@redhat.com>]

Sam Joyce wrote:
> Hi Folks,
> I'm new to the list and I'm coming to grips with QMF at the moment and 
> have a thought that may be of interest. I was talking with some folks 
> last week about managing large numbers of nodes; cloud/grid where there 
> are typically thousands of managed elements.
> In some cases, e.g. purging a queue, there may be application level 
> logic as to which queues need to be purged and when. using the existing 
> QMF tooling this would be fairly time consuming from a sysadmin 
> perspective.
> Don't get me wrong, I like the current interface and its in keeping with 
> the tooling for most other message based admin systems that I've used.
> So, an idea for discussion: what if managed elements could "subscribe" 
> for certain management events. In a large scale deployment, the sysadmin 
> wouldn't need to know which nodes to manage explicitly and would instead 
> "publish" a management event, like "purge backout queues for app X"
> I know my use of "publish" and "subscribe" isn't quite correct in qpid 
> terms, but I hope you get the idea.
> thoughts?

Conceptually there is no reason you couldn't set up a topic and 
broadcast commands to anyone listening, however, there is no builtin way 
of knowing who is listening, so it would be difficult to determine when 
all the subscribers have completed a command, i.e. it would be hard to 
tell when the aggregate operation is complete.

--Rafael

---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org