RE: [amqp] RE: AMQP Management Workstream

["Rob Dolin (MS OPEN TECH)" <robdolin@microsoft.com>]

THANK YOU very much Rafael for your thoughtful comments.

I'm going to work on addressing / incorporating them into a Doc using track changes and will schedule a ConCall with shared screen for review next week.  Please let me know if you have any conflicts with the following days/times:
* Tue, 11am Eastern / 8am Pacific
* Tue, 1pm Eastern / 10am Pacific
* Wed, 11am Eastern / 8am Pacific

If others have comments, please also share on the list.

Thanks very much--
--Rob D.

P.S. Once the call is scheduled, I'll send the info to the AMQP TC so folks who are interested in participating can join.


-----Original Message-----
From: Rafael Schloming [mailto:rafaels@redhat.com] 
Sent: Wednesday, May 15, 2013 9:08 AM
To: Rob Dolin (MS OPEN TECH)
Cc: amqp@lists.oasis-open.org
Subject: Re: [amqp] RE: AMQP Management Workstream

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.
> 
>  
> 
>