Re: [amqp] RE: AMQP Management Workstream

[Rafael Schloming <rafaels@redhat.com>]

I've been working through the document and do have some comments. I'll
summarize them below. I'm happy to discuss over email or at a call,
whichever you prefer.

  - Section 3, the treatment of case seems to be confusing/inconsistent.
The first para has operations in lowercase, the second in uppercase, and
the table in 3.1 says that the operation is case sensitive and then goes
on to say that it SHOULD be in ALL UPPERCASE. This confused me at first
because if the field is case sensitive then it needs to match exactly
how the operations are defined, so simply defining the standard
operations to be "CREATE", ... rather than "create" should be
sufficient. I think what is being said in the latter part is really
attempting to establish a naming convention about how custom operations
should be defined and as such is not really directly related to the
formal definition of the field. I would suggest it would be clearer to
either define it elsewhere or simply omit it entirely. (As an aside, the
example in para 2 of section 3 seems to violate this naming convention:
"CreateNewTopic")

  - Section 3.1: the locales description was a bit confusing, it took me
a reread to figure out that it was talking about what locale to use for
the response.

  - Section 3.3 (UPDATE): are updates atomic?

  - Section 3.3 (READALL): if this does get extended to include filters,
e.g. as suggested on type, then READALL might be a bit of a misnomer. It
also occurs to me that the response could end up being very very large
if you are indeed querying all manageable objects for a given system,
even if you can restrict to a given type. This brings to mind more
generic filtering/querying capabilities. I know pagination is something
that consoles will run into right away. Perhaps we should consider the
pros/cons of defining a standard way to do paging and/or querying in
order to handle incrementally reading and/or narrowing the subset of
data.

  - Section 3.3 (DISCOVER): this seems to be mixing both metadata
(information about the types and operations) with operational data (the
names of the actual instances). One question that comes to mind is why
include names but not ids? This seems like it could lead to confusion if
the names change. Perhaps the ids should be included also in these sorts
of list results. Secondly, I don't think it is a good idea to mix
metadata and operational data in this way. It strikes me that management
consoles would likely want to be able to query these separately, e.g.
query the metadata alone on startup when configuring the UI and then
separately refresh operational data as things change. Forcing both the
metadata and the operational data to be pulled down at the same time
seems both less efficient and more awkward for at least some scenarios.

  - Section 3.3 (DISCOVER-MGMT-NODES): The model in general here could
use some more explanation. I struggled to figure out why you needed so
many different operations that all basically boil down to directory
listing, and to be honest I'm not convinced you actually do need so many
different ones. It would be possible to collapse these with some
changes/simplification to the model. It appears there are at least 3
different naming schemes involved here: ids, names, and addresses.
Furthermore addresses are used in two ways. A manageable entity such as
a queue might have an address, and a manage*ment* entity might be
accessible via an address. At a minimum this needs to be explained
better, but IMHO could use some simplification.

  - Section 3.3 (REGISTER & DEREGISTER): this functionality seems odd to
me as part of a basic manageable entity. This would seem to imply that
all management nodes need to function as general purpose directory
services.

General comments:

  - It seems odd to use names as keys for operations when we have unique
and immutable ids, renaming comes to mind as something that would be
more obvious/possible this way.

  - Overall I found it difficult to decipher the data structures as
presented. There are actually a whole lot of highly structured types
being defined here via English. It would be a whole lot more precise to
model these via formal XML definitions.

  - There doesn't seem to be any notion of events or live updates or
stats. This can to some extent be treated as an orthogonal problem and
addressed as an independent chunk of work, but it would be nice to see
some early thinking about if/how this would intersect.

  - It might be nice to have some way to get a hint of how many results
there are likely to be from the directory listing operations. That would
at a minimum allow a console to avoid pulling over more information than
it can usefully/conceivably display. You can also imagine adding some
kind of limit to get only the first N results back.

--Rafael

On Tue, 2013-05-14 at 17:27 +0000, Rob Dolin (MS OPEN TECH) wrote:
> I’m writing to see if there is interest in having a ConCall about the
> AMQP Management draft between now and the next AMQP TC meeting.
> 
>  
> 
> If you would be interested, please reply including your time zone and
> I’ll look to schedule at a mutually convenient (or at least not too
> inconvenient) time.
> 
>  
> 
> Thanks—
> 
> --Rob D.
> 
>  
> 
>  
> 
>  
> 
> (from:
> https://www.oasis-open.org/apps/org/workgroup/amqp/download.php/49168/Minutes%20from%20the%202013.05.14%20AMQP%20TC%20meeting.htm)
> 
>  
> 
>      1. Discuss progress on core extension Work Products (Global
>         Addressing, management/monitoring, distributed transactions,
>         claims based security, etc.) 
>              a. Timeline for the various Work Products?
> 
>  
> 
> Management spec: The TC unanimously
> approvedhttps://www.oasis-open.org/apps/org/workgroup/amqp/email/archives/201305/msg00005.html as Working Draft 01. Member are requested to review the draft and provide comments. During the next meeting on May 28, 2013, the TC will review the comments received and discuss about advancing the management spec to Committee Specification Draft 01 (CSD01). Note, Committee Specification Drafts in general represent stability and general consensus. The TC may produce as many CSDs as required before advancing to Committee Specification (meaning feature complete and a step closer to Candidate OASIS Standard en route to an OASIS Standard).
> 
>  
> 
>  
> 
> From: Ram Jeyaraman (MS OPEN TECH) 
> Sent: Monday, May 13, 2013 11:20 AM
> To: Rob Dolin (MS OPEN TECH); amqp@lists.oasis-open.org
> Subject: RE: AMQP Management Workstream
> 
> 
>  
> 
> Thank you Rob and the management work stream for putting this initial
> draft together. Let’s discuss this during the May 14th TC  meeting and
> determine the next steps. I like to get some clarity on the relative
> maturity of this draft and the timeline to CSD01.
> 
>  
> 
> From: amqp@lists.oasis-open.org [mailto:amqp@lists.oasis-open.org] On
> Behalf Of Rob Dolin (MS OPEN TECH)
> Sent: Sunday, May 12, 2013 10:05 PM
> To: amqp@lists.oasis-open.org
> Subject: [amqp] AMQP Management Workstream
> 
> 
>  
> 
> Fellow AMQP TC members,
> 
>     Attached is an initial proposal from the management workstream.  
> 
>  
> 
>     All wise ideas are credit to the folks who attended the last
> face-to-face meeting, David I., Rafael S., and Rob G.; all typos,
> omissions, and bad ideas are mine.  
> 
>  
> 
>     Feedback would be most welcome via email; and if there is
> controversy, I will schedule a ConCall.  
> 
>  
> 
> Thanks very much—
> 
> --Rob D.
> 
>  
> 
>  
> 
> (from:
> https://www.oasis-open.org/apps/org/workgroup/amqp/download.php/49014/Minutes%20from%20the%202013.04.30%20AMQP%20TC%20meeting.htm) 
> 
>      1. Discuss progress on core extension Work Products (Global
>         Addressing, management/monitoring, distributed transactions,
>         claims based security, etc.)
> 
>  
> 
> The Chair reminded the work streams to prepare a timeline for the
> various Work Products and have it ready if possible by May 14, 2013.
> And asked the work stream leaders to post the dial-in #s for the
> meetings.
> 
>  
> 
>