qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Fraser Adams <fraser.ad...@blueyonder.co.uk>
Subject Re: The future of Qpid Management.
Date Thu, 27 Feb 2014 17:57:49 GMT
On 26/02/14 21:38, Gordon Sim wrote:
> On 02/26/2014 08:00 PM, Fraser Adams wrote:
>> On 26/02/14 11:43, Gordon Sim wrote:
>>> That said I don't believe one single source of information is ever
>>> likely to be (and remain) sufficient for a tool that can be used with
>>> multiple different brokers (there will always be 'extensible'
>>> elements, such as the queue-declare 'arguments' for which you will
>>> need to consult some other source of documentation).
>> Perhaps, though I'd argue that it's just a recursive type - so you
>> supply a Map parameter and describe the properties of the Map and their
>> types. Ultimately to be of use this stuff has to be described
>> *somewhere*, making said documentation *structured* doesn't then seem
>> unreasonable.
> Just to be clear, I wasn't saying that such information *couldn't* be 
> defined in a broker specific schema, just that there isn't going to be 
> one document (schema or other) that has all the extensions for all the 
> brokers in it.
>> I'm probably on a losing streak with this, but at least you guys know
>> where I'm coming from now, if there are better approaches to document
>> this and better ways to make sure that said documentation does in fact
>> happen then I'll go with the flow.
>>> Neither am I in any way advocating for or against schema retrieval
>>> mechanisms.
>>> I do think a generic tool for in some way 'managing' - e.g. like
>>> qpid-config add|del|list or a gui equivalent - a range of different
>>> brokers, each with divergent but overlapping sets of semantics, is
>>> both feasible and (potentially) useful. I'd be interested to hear
>>> other opinions on that though, especially with regard to usefulness.
>> I'd agree that it's a difficult one. My gut feeling is that with the
>> right sort of schema (and perhaps by "right" this includes annotations)
>> then at the very least it will be a whole lot easier to write more
>> general tooling.
> I think it could certainly provide some 'dynamic' documentation, 
> tailored to the broker in question.
>> It's not black and white by any means - for example I
>> look at management-schema.xml and look at the QMF GUI and I've made
>> "judgement calls" on some of the properties that just take up real
>> estate and those which are useful and TBH I have "coded" pages for
>> specific Node types, but I do often wonder if I could make things more
>> general.
> This is somewhat similar to qpid-config, though it also adds some 
> unnecessary (in my view) specific code to give different special names 
> to some options. However it does now also have a fallback to something 
> more completely generic (which I wanted for some of the new entities I 
> was experimenting with). It would in this context by noce to be able 
> to do something like e.g. qpid-config schema to get a list of the 
> supported types and their attributes... a dynamic usage statement, 
> driven by the broker connected to if you will.
>> Perhaps the differences between the C++ and Java Brokers gives us a
>> chance to figure out if it's actually possible to do useful "generic"
>> tooling.
> Haven't you to some extent already done that with your QMF adapter 
> work? Not that I'm saying that adaptation to QMF is the way forward, 
> just that its possible to present a reasonable unified impression over 
> the two, even though they aren't entirely unified in reality.
Yeah I'm *relatively* content with how that turned out, as you know in 
part at least what I did was intended as something of a "statement" to 
illustrate that this sort of thing was possible and probably a good 
thing, though I won't pretend it's perfect.

With a lot of what I'm saying I'm trying to be deliberately provocative, 
as I said in my earlier mail it's *really* the fact of having decent 
documentation that I care about, but I think that there needs to be some 
sort of "forcing function" to make this more than just a "nice to have".

I've got some sympathy with Rob's comments "The basic operations are 
fine and work OK out of the box... but what one might consider the 
"bespoke" operations really don't because although the meta-data exists 
it's really not enough to build a useable user interface... Sure the 
parameter is a String, but actually it has to come from a constrained 

TBH I'm actually no great fan of things like JMX Consoles for a lot of 
the reasons mentioned and clearly the QMF GUI is itself "bespoke" - it 
clearly does slightly different things for Exchanges and Queues and, 
well Bindings needed a *whole bunch* of thought to try and figure out 
how to represent them :-). But that said I suspect that AMQP Management 
Agents/Manageable Entities although fairly general aren't likely to be a 
general as say Java Objects and are likely to follow a relatively few 
"patterns" so with decent annotations I have a feeling (but no proof) 
that it'd be possible to have something fairly general that still looks 

On Rob's "Sure the parameter is a String, but actually it has to come 
from a constrained type.." actually I think that XMI would allow you to 
describe this sort of thing - though it wasn't really a serious 
suggestion more just a bit of interesting food for thought (I wouldn't 
want to generate XMI by hand) :-)

I mentioned previously that I think that the biggest source of real 
awkwardness is in the area of associations between Manageable Entities 
and how one goes about navigating.

In the QMF UI there was a fair bit of effort put in to making this sort 
of thing efficient, so I pulled in the Objects I cared about and indexed 
them in a Map so that reference properties could be dereferenced easily 
and cheaply, being able to navigate from say a Queue to a Connection or 
vice versa is fairly useful to me, but it's not especially simple and 
that was one of the more interesting aspects of doing the mapping from 
the Java Broker's internal Management Model to QMF.

So to get back to your point "Haven't you to some extent already done 
that with your QMF adapter work" well yes, but it's not actually a 
simple yes/no answer. The core properties/attributes all map fairly 
easily and I could probably have got away without actually mapping those 
because I introspected the names (I'll say why I did in a bit) but I 
*certainly* needed to do something about the navigation because QMF and 
the Java Broker Management Model take very different approaches. That's 
why I'm a little troubled that AMQP 1.0 Management is agnostic about 
navigation/association that's one of the hard bits and if everyone does 
their own thing then it'll make it very hard indeed to create tooling 
that's not very bespoke.

As it happens I actually mapped the properties because I was keen to see 
if I could get it to work with the CLI tools such as qpid-config (as I 
say it'd probably have looked decent with the UI with only the 
navigation mapped). I mention that because I think migration from 
existing tooling is going to be one of the more "interesting" aspects of 
moving to AMQP 1.0 Management. So as you know I did a Java Broker 
plug-in that does the mapping 'cause that was a fairly obvious place, 
but if both C++ and Java Brokers talk AMQP 1.0 Management there's no 
obvious place to do mappings - I guess that the best hope in that case 
would be something like the client side of qpidtoolibs and similar for 
Java and C++, but I haven't though too hard about it yet (it's likely to 
need to happen in multiple places though rather than in the one place it 
currently happens).

You'll recall a few threads on "Plans for QMF v1 and v2" last Easter 
that were spawned on the back of plans to disable v1 push messages from 
qpidd by default and the resulting realisation that the Python 
asynchronous API only really worked for v1 at the time. I think that's 
probably the tip of the iceberg compared to migrating to AMQP 1.0 
Management. Perhaps the right answer is not to migrate but rather make a 
clean break with new tools? I don't know, do you guys have a preference?


To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org

View raw message