David and Rob G.,
I understand that people would like more time to review the AMQP Management draft and provide feedback via email. I am canceling the below meeting scheduled for 30 minutes from now.
Would you please add discussion of the AMQP Management draft to the agenda for the AMQP TC meeting on Tue, 2013-05-28? (I looked for other times but Monday, 2013-05-27 is a holiday in the USA.)
Thanks very much—
--Rob D.
-----Original Appointment-----
From: Rob Dolin (MS OPEN TECH)
Sent: Monday, May 20, 2013 4:08 PM
To: Rob Dolin (MS OPEN TECH); rafaels@redhat.com
Cc: amqp@lists.oasis-open.org; James Kirkland; Jakub.Scholz@deutsche-boerse.com; Steve Huston; Dale Moberg; Kritikos, Alex
Subject: AMQP Management Workstream
When: Tuesday, May 21, 2013 8:00 AM-9:00 AM (UTC-08:00) Pacific Time (US & Canada).
Where: Lync: +14257063500 | 282 415 439 #
Hi Rafael,
I’m hoping this time tomorrow (after the AMQP BindMap TC meeting) might work for discussing your feedback on the AMQP Management spec. Thanks very much—
--Rob D.
(See bottom of email for hyperlinks to call-in numbers)
-----Original Message-----
Sent: Friday, May 17, 2013 6:52 AM
Subject: RE: [amqp] RE: AMQP Management Workstream
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-----
Sent: Wednesday, May 15, 2013 9:08 AM
To: Rob Dolin (MS OPEN TECH)
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
.........................................................................................................................................
Join by phone
+14257063500 (USA - Redmond Campus) English (United States)
+18883203585 (USA - Redmond Campus) English (United States)
Conference ID: 282 415 439
[!OC([1033])!]
.........................................................................................................................................