[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [amqp] RE: AMQP Management Workstream
Hi Rob, Thanks for preparing the first draft and for organizing the conference calls. Bellow are my questions / review comments to the document ... 1) According to 2.4, "This specification does not define the collection of supported Manageable Entity Types". Where will they be defined? I assume the entities org.amqp.* mentioned in 2.2 should be defined somewhere by the AMQP TCs. Together with the list of the entities, we might also include some recommended attribute names to avoid incompatibilities between implementations even for a basic stuff. 2) According to 3.3, the management node should respond with a message containing a body with a map of the actual attributes. These attributed may differ from those required. Does it mean that the management node can change any attribute as it wants and still return success? What should be the main benefit of giving such freedom to the management node? 3) What is the expected response if some of the operations in chapter 3 are not supported for certain manageable entities? 501 Not Implemented? 4) For all defined operations, we say that the response must be empty in case the request was unsuccessful. Shouldn't this be also part of the chapter 3.2 to enforce this rule also on any custom operations the builders may implement? 5) As already mentioned by Rafael, some sort of handling for large data sets for READALL and DISCOVER operations might be very useful 6) What is the difference between "All manageable entities" and "all ManageableEntities on which Management Operations can be performed"? (READALL versus DISCOVER) How should these terms be interpreted when the management node has some security layer which allows different users manage different entities / use only some selected operations? 7) The READALL and DISCOVER operations are partially overlapping. Maybe we can move the first part of the DISCOVER functionality - "(a) the list of ManageableEntities on which Management Operations can be performed" - as one of the filtering possibilities for READALL. 8) While the description of the DESCOVER-MGMT-NODES, REGISTER and DEREGISTER operations is quite clear, I'm missing some kind of explanation what is their purpose. 9) The document describes only request/response processing. Is there some reasons why we do not want some sort of management broadcasts? Thanks & Regards Jakub ---------------------------------------------------------------------------- Deutsche Börse Services s.r.o. Managing Directors/Geschäftsführung: Michael Gassmann, Mats Andersson. Limited liability company with registered office at Sokolovská 662/136B, CZ-186 00 Prague 8 recorded in the Commercial Register IC: 275 77 015. Maintained by the city court in Prague, Sec. C, File No. 116874. |---------------------------+---------------------------------------------------------------------------------------------------------> |"Rob Dolin (MS OPEN TECH)" | | |<robdolin@microsoft.com> | | |Sent by: | To| |<amqp@lists.oasis-open.org>| "rafaels@redhat.com" <rafaels@redhat.com> | | | cc| | | "amqp@lists.oasis-open.org" <amqp@lists.oasis-open.org> | |17/05/2013 15:52 | 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----- 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. > > > > ----------------------------------------- Diese E-Mail enthaelt vertrauliche oder rechtlich geschuetzte Informationen. Wenn Sie nicht der beabsichtigte Empfaenger sind, informieren Sie bitte sofort den Absender und loeschen Sie diese E-Mail. Das unbefugte Kopieren dieser E-Mail oder die unbefugte Weitergabe der enthaltenen Informationen ist nicht gestattet. The information contained in this message is confidential or protected by law. If you are not the intended recipient, please contact the sender and delete this message. Any unauthorised copying of this message or unauthorised distribution of the information contained herein is prohibited. Legally required information for business correspondence/ Gesetzliche Pflichtangaben fuer Geschaeftskorrespondenz: http://deutsche-boerse.com/letterhead
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]