Robert Greig wrote:
On 14/03/2008, Carl Trieloff <[EMAIL PROTECTED]> wrote:
sure, as you know qpid get's included into fedora, this feature has been
picked up to also
transport OS info, CPU, interrupts, network etc.
Another project that I know that has picked it up is looking to push
data around hypervior info
And yet another is doing work laying sec alerts, and resource
utilization over the same mechanism. It turns
out it is very easy to create another mgmt object and integrate it.
Interesting. This raises some further questions in my mind:
1) What applications/tools view and process the data? i.e. if a group
puts CPU info into the management messages, what do they read it in?
this is what is impl in the C++ broker so far:
https://svn.apache.org/repos/asf/incubator/qpid/trunk/qpid/specs/management-schema.xml
Also, to play with it there is are a few options, easiest is the following
https://svn.apache.org/repos/asf/incubator/qpid/trunk/qpid/python/mgmt-cli/main.py
is an interactive cmd line test tool.
2) For some of these it sounds like the message format is being used
as a general format for management info that is pretty much
independent of the broker (or Qpid).
yes.
Is this intended to replace or
compete with WS-M?
WS-DM is hell on so many levels, that my view is to only use it for
integration with BMC,
Tivoli etc.
not yet ... but multiple parties in AMQP Working Group have expressed
support for it, one
of the rabbit users has been working with it also - I am sure hit will
get updated somehow before
making it's way into a release. Discussion so far is in the WG is that
it would be optional to impl as part
of the spec.
The advantage of this I suppose is that if multiple broker
implementations supported it, users could manage their installations
from a single tool. Or, more realistically, if users wrote scripts
against the JMX interface, those would be portable across different
brokers.
yes.
I think it would be useful to know how concrete the Rabbit (or other
vendor) plans are.
time will tell
yes agree, thus I was suggesting that it is nice project for someone to
pick up, so the
bridge exists and then makes it valuable for Java broker when it gets to
it. The questions
is -- if we do a bridge as a project would that also be interesting for
the Java broker down the road?
I think it would be interesting. Even in the short term, it would be
useful for the C++ and Java brokers to share the management verbs and
properties. From a user perspective if the bridge supported WS-M and
JMX then the C++ (via the bridge) and Java brokers (natively) would in
theory support the same set of tools.
yes, that is my thinking.
yes, there are two places we can map this, at the broker into the
AMQP-mgmt protocol or
at the impl of the bridge. I think the former is the better approach --
please comment if you
don't agree
I think that AMQP-mgmt is a better approach if it gets proper buy-in.
agree.
Carl.
