qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Godfrey <rob.j.godf...@gmail.com>
Subject Re: New draft of OASIS AMQP Management specification uploaded
Date Wed, 12 Feb 2014 20:39:08 GMT
To be fair it's a very rudimentary implementation... But on trunk at the
moment is a plugin where you can execute all of the management operations
except those relating to discovering other management nodes (since there
aren't any at the moment)... you can also also read, update, delete and
create queues and exchanges. I'm currently working on being able to expand
that to being able to create other entities that live within the virtual
host.  Also I'll probably do a little work to make it easier to
send/receive messages management messages over AMQP 0-8/9/10 as well as
AMQP 1-0.

For things that live outside the virtualhost (which is quite a lot in the
Java broker), I'm thinking of creating a synthetic virtualhost which is
only used for management... but that's not much more than vague aspiration
at the moment.

Ideally I'd like to get a lot of this stuff in for 0.28, but it may slip a
bit beyond that (depending on when 0.28 actually gets cut) and obviously
it's rather at the mercy of changing specs at OASIS.

-- Rob


On 12 February 2014 21:31, Fraser Adams <fraser.adams@blueyonder.co.uk>wrote:

> Hi Rob,
> I'll take a look at draft 5 when I get a moment - I was looking at draft 3
> (which is the one that you linked when you posted on the 14th January).
>
> What you are saying sounds a bit more promising. I hadn't realised that
> you were ahead of the curve with respect to implementing this stuff in the
> Java Broker, now you're just showing off :-D
>
> Frase
>
>
> On 12/02/14 19:21, Rob Godfrey wrote:
>
>> Hi Fraser,
>>
>> not sure what version you are looking at, but working draft 5 (
>> https://www.oasis-open.org/committees/download.php/52121/
>> amqp-man-v1%200-wd05.pdf)
>>   already specifies that attributes on QUERY is optional, and there is a
>> GET-ATTRIBUTES operation as well.
>>
>> The create thing is a bit odd, I grant you... the subject of the create
>> command does not yet exist, whereas for read, update and delete clearly
>> the
>> subject does already exist and the name (or identity) in the headers is
>> pointing to it.
>>
>> After having implemented on my branch for the Java broker (and in fact
>> landed on trunk now) personally I'd probably prefer dropping "name" from
>> the headers and instead using ID as the only way to direct operations to
>> objects (the name would still be a mandatory attribute).  For create the
>> IDENTITY header must not be supplied (the name will be in the map of the
>> attribute values).
>>
>> Hope this helps,
>> Rob
>>
>>
>> On 12 February 2014 19:40, Fraser Adams <fraser.adams@blueyonder.co.uk
>> >wrote:
>>
>>  On 14/01/14 14:24, Rob Godfrey wrote:
>>>
>>>  All,
>>>>
>>>> for those interested in emerging OASIS AMQP specifications, a new draft
>>>> of
>>>> the AMQP Management spec was uploaded yesterday:
>>>>
>>>> https://www.oasis-open.org/committees/document.php?
>>>> document_id=51948&wg_abbrev=amqp
>>>>
>>>> Cheers,
>>>> Rob
>>>>
>>>>   Rob et. al. it's been a while since I looked at this in anger, but
>>>> I've
>>>>
>>> just had a look at the latest draft linked above and thought I'd share
>>> the
>>> following. Perhaps you or others can reassure me - or perhaps this might
>>> prompt people who are currently used to using QMF to read the AMQP 1.0
>>> Management Spec. and give Rob their own comments (the following will
>>> probably only make any sense if you've looked at the Spec.).
>>>
>>> I'm still quite nervous of the AMQP 1.0 Management stuff if I'm honest, I
>>> have to confess that I don't find the way that the specification is
>>> written
>>> the easiest to follow - for example section 3 says "All manageable
>>> entities
>>> SHOULD support standard manageable entity operations such as CREATE,
>>> READ,
>>> UPDATE, and DELETE." but 2.4 for example says " A Manageable Entity MAY
>>> be
>>> an addressable Node (e.g., a queue) ". That conceptually feels odd to me
>>> -
>>> applying CRUD methods to something that may not actually exist. I guess
>>> what it's *really* suggesting is that the CRUD methods are class  methods
>>> (in UML terms) but it feels weird - especially as later in section 5.2 it
>>> says:
>>>
>>> // transfer a request message
>>>
>>> requestLink.sendTransfer(
>>>
>>> Message(
>>>
>>> properties: {
>>>
>>> correlation-id: 1,
>>>
>>> to: "$management",
>>>
>>> reply-to: "/myaddress"
>>>
>>> },
>>>
>>> application-properties:{
>>>
>>> "name"->"newQueue",
>>>
>>> "operation" -> "CREATE",
>>>
>>> "type" -> "org.example.queue"
>>>
>>> },
>>>
>>> application-data:AmqpValue(
>>>
>>> Map(
>>>
>>> //typespecificproperties
>>>
>>> "max_size"->"2000Mb"
>>>
>>> )
>>>
>>> )
>>>
>>> )
>>>
>>> )
>>>
>>>
>>>
>>> To my mind that looks like it's sending a message to "$management", so
>>> I'd
>>> personally interpret that in my own mind as actually invoking a CREATE
>>> method on the management *node* e.g. create an "org.example.queue" called
>>> "newQueue"which TBH is pretty close to what the broker object currently
>>> does in QMF.
>>>
>>> I might be reading too much into things, but it does leave me properly
>>> confused.
>>>
>>>
>>> Though I'm a lot more concerned by the apparent lack of a mechanism to be
>>> able to retrieve all objects of a given type. So a READ mechanism exists
>>> to
>>> retrieve the attributes of a given Manageable Entity. And there's a
>>> GET-TYPES to retrieve the available Manageable Entity types but the QUERY
>>> method still doesn't seem to cut it for me.
>>>
>>> What I mean is that QUERY has a *mandatory* Attributes Key and an
>>> optional
>>> entityTypes. What that means is that it's possible to filter on say
>>> "org.example.queue", but you have to specify the " set of attributes of
>>> the
>>> Manageable Entities being requested. ". Firstly it doesn't say the form
>>> of
>>> the set of attributes other than a string - so if more than one what's
>>> the
>>> separator (I'd assume comma separated, but it doesn't say). But TBH I'd
>>> much prefer the Attributes bit to be optional so if I specified
>>> "org.example.queue" I'd get back the complete object (e.g. like the QMF
>>> getObjects).
>>>
>>> It's certainly good to be able to ask for specific attributes and I'm not
>>> suggesting that shouldn't be possible too, but I don't like getting
>>> forced
>>> to. At the moment I can essentially introspect the retrieved objects and
>>> the GUI can actually be quite agnostic if new attributes get added (give
>>> or
>>> take a few cases where you might want to represent things in a particular
>>> way such as references). It's actually worse than I'm making out because
>>> a
>>> GET-OPERATIONS method has been specified, but no GET-ATTRIBUTES, so I
>>> actually end up having to know a whole bunch of things a-priori that I
>>> don't currently do.
>>>
>>> "getObjects" is TBH is pretty much *the* core use case of all of the
>>> current QMF based tools? Knowing all of the attributes a-priori doesn't
>>> appeal, but retrieving objects individually by repeated calls to READ
>>> *really* doesn't appeal.
>>>
>>> I'd definitely like QUERY (or similar) to have Attributes as optional and
>>> if it's not sent to return a List of Maps of properties and their keys
>>> (like getObjects and like READ does for a single Object) rather than a
>>> List
>>> of Lists of values. As I say I'd agree that the latter is useful too, but
>>> the former is incredibly useful and having it would certainly make
>>> migration from QMF2 to AMQP 1.0 Management a whole lot more
>>> straightforward.
>>>
>>>
>>> Best Regards,
>>> Frase
>>>
>>>
>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message