Trouble Ticket Exchange Specification. This draft invites discussions and suggestions for improvements. The distribution of the document is unlimited.

Transcription

1 GWD-?? E. Baldonado Grid User Services Working Group Sandia National Laboratory dast.nlanr.net/gridforum/userserv-wg February 2002 dast.nlanr.net/gridforum/userserv-wg/documents/?? Trouble Ticket Exchange Specification Status of this Draft Trouble Ticket Exchange Specification This draft invites discussions and suggestions for improvements. The distribution of the document is unlimited. Copyright Notice Copyright Global Grid Forum (2001). All Rights Reserved. 1 Abstract In the coming era of computational and data grids, problems will certainly arise which involve two or more these grids. A concise, consistent trouble ticket interchange standard will greatly assist systems and user services groups responsible for supporting these grids. These groups, which support their different communities of grid users, are assumed to all use some form of trouble ticket system to track their response to users problems. The object of creating a trouble ticket interchange format is to enable these groups to easily communicate and track problems, which span grids. E. Baldonado <ebaldon@sandia.gov> [Page 1]

2 Table of Contents 1 Abstract A Support Model...Error! Bookmark not defined. 3 Summary/Conclusions Security Considerations Author Contact Information Intellectual Property Statement Full Copyright Notice Appendix A: Sample Representation - XML Essential elements The following are eight essential elements that need to be exchanged between groups supporting grids: (Field: User) Originator The originator of the trouble ticket. This would be the user or systems support organization that has fielded the user problem and has created a trouble ticket. The Originator may be a collective ( NCSA Consulting Office ) or individual ( Jane Doe NASA Ames SysAdmin ) but should try to be somewhat descriptive as the two examples are above. (Field: Problem Text and/or Activities) Originator self-explanatory (Field: Number) Originator Ticket Number This is the trouble ticket number created by the Originator in their own local trouble ticket system. This number, coupled with the Originator s will give a unique identifier to each interchanged trouble ticket. (Field: Problem Text and/or Activities) User self-explanatory. This may be None if the Originator chooses not to associate this ticket with any single User. (Field: Response Requested) Response Requested - <Yes No> Some tickets passed along to other grids support groups will be informational or advisory in nature, and may not require a response. (Field: Response Requested) Respond to User - <Yes No> In some cases the Originator of the ticket may want any responses copied directly to the User involved. In other cases, the Originator may want to filter for any responses to the User. (Field: Problem Text) Problem Description This is the main body of the ticket, with as complete a description of the problem as possible. We can avoid requiring other ticket exchange fields such as hardware, software, system, etc. by relying on the problem description to carry the weight of the trouble ticket. (Field: Priority.. We have 1,2,3) Priority - < > A measure of urgency from 1=critical, to 4=low priority. This could perhaps be whittled down to just two priorities critical and other. (The tendency to over prioritize should be avoided, else everything will become critical. Normal problems with processing should start out as a 2. Since one of the basic ideas behind the grid is the utilization of spare cycles, there shouldn t be a big rush to process in the foreground.) Responses to Originator E. Baldonado <ebaldon@sandia.gov> [Page 2]

3 When responding to the Originator of a trouble ticket, the most critical element to return (besides the actual reply or answer to the problem) is the Originator Ticket Number. This allows the Originator to smoothly track the ticket and resulting responses within their own ticket system. It s probably a good idea to return this ticket number in both the Subject line of the return as well as reference it prominently near the top of the response to the problem. (Every that is sent through the ticketing system automatically picks up the ticket number as part of the subject line this is the preferred method of communication, rather than a separate outside the ticketing system.) Format for Ticket Interchange files A simple format for trouble tickets to be interchanged is probably the best. Most trouble ticket systems can be modified to use a script to output or input a simple ASCII file. A simply formatted file also allows those groups without sophisticated ticketing systems to understand what the key points are in the incoming trouble ticket. (This sounds like something the database people may comment on or address.) Each essential part of the interchange trouble ticket will be marked with a <label> to indicate what piece of information is being conveyed. This might best be described in a sample: <originator>nkba Consulting Office <originator >consult@nkba.edu <originator ticket> <user >janedoe@stateuniversity.edu <response request>yes <respond user>no <priority>2 <description>the user is attempting to transfer a large number of files from a mass storage device (massfiles.nkba.edu) at NKBA to a file server (bigfileserver.senator.nasa.gov) on the NASA Grid. The user s ID on the NASA system is janedoe7. The connection seems to be made, but performance is low and then the connection is dropped within 5 minutes each attempt. The user claimed to have tried this 5 or 6 times and observed this behavior each time. Network and system administrators at NKBA have detected no problem on their end, which is backed by no other user complaints lodged regarding either the mass storage system at NKBA or the network connect. Can you help us out? 3 Protocols Some protocols for handling tickets between grid support organizations will need to be developed, though those may be beyond the scope of this white paper. Some basic protocols will be obvious, such as sending an immediate courtesy response upon receiving a ticket, and having the ticket Originator ultimately responsible for the outcome and closing of the ticket. Other protocols involving things like time to wait before inquiring of status, will have to be worked out among groups supporting the grids. 4 Summary/Conclusions 5 Security Considerations Though this document does point out the need in various areas to define the security practices to be used in a particular Grid environment, it does not advocate the use of particular policies or technologies to implement those policies. 6 Author Contact Information Esther Baldonado Sandia National Laboratory [address] E. Baldonado <ebaldon@sandia.gov> [Page 3]

4 Sandia NM [zip code], USA ph:+1-xxx-yyy-zzzz fx: +1-xxx-yyy-zzzz 7 Intellectual Property Statement The GGF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the GGF Secretariat. The GGF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this recommendation. Please address the information to the GGF Executive Director. 8 Full Copyright Notice Copyright (C) Global Grid Forum (2001). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the GGF or other organizations, except as needed for the purpose of developing Grid Recommendations in which case the procedures for copyrights defined in the GGF Document process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the GGF or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE GLOBAL GRID FORUM DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. E. Baldonado <ebaldon@sandia.gov> [Page 4]

5 9 Appendix A: Sample Representation - XML E. Baldonado <ebaldon@sandia.gov> [Page 5]