On 27 February 2014 18:57, Fraser Adams <[email protected]>wrote:
> 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 type.." > > 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 "nice". > > 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. > > I think this is a valid point... It's probably a worthwhile exercise to think about the "standard" AMQP 1.0 entities and how they will be modelled and their relationships. For AMQP 1.0 that probably starts of consisting of "Nodes", "Links" and "Connections" (and possibly "Sessions"). In the general AMQP model exchanges and bindings don't exist - though we could maybe model them as node and bindings as "internal links" between nodes. > 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). > > I think properties and associated behaviours is something we should definitely be standardising between implementations under the Qpid umbrella, and looking to standardize amongst other AMQP implementations. That's not to say that all implementations will offer the same set, just that we should (and I feel I've said this a million times already) use the same properties and the same values for the same behaviours. Personally I think the biggest gap in the AMQP 1.0 management stuff right now is any common way of describing "events" and a way to subscribe to them, whether that be getting period statistic updates, or notification of objects being created / deleted / etc. I feel that this is a common use case and again by standardising we would enable a broad class of use-cases to be enabled in a standard way without being overly prescriptive about exactly what statistics might be supplied (number of mallocs anyone :-) ). > 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? > > On the Java side we'll continue supporting the existing management mechanisms (which are implemented as plugins) but out internal tooling will be focussed on AMQP manegement alongside the REST/API where appropriate. We will be trying very hard to keep the two of these using the same model so transitioning from one to the other should be seemless. -- Rob > Cheers, > Frase > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
