GWD-?? E. Baldonado Grid User Services Working Group

advertisement
GWD-??
Grid User Services Working Group
dast.nlanr.net/GridForum/UserServ-WG
dast.nlanr.net/GridForum/UserServ-WG/Documents/??
Trouble Ticket Exchange Specification
E. Baldonado
Sandia National Laboratory
February 2002
Trouble Ticket Exchange Specification
Status of this Draft
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]
GWD-??
February 2002
Table of Contents
1
2
3
4
5
6
7
8
Abstract .................................................................................................................................................. 1
A Support Model ................................................................................... Error! Bookmark not defined.
Summary/Conclusions............................................................................................................................ 3
Security Considerations.......................................................................................................................... 3
Author Contact Information ................................................................................................................... 3
Intellectual Property Statement............................................................................................................... 4
Full Copyright Notice............................................................................................................................. 4
Appendix A: Sample Representation - XML ......................................................................................... 5
2
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 email – 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 email will give a unique identifier to
each interchanged trouble ticket.
(Field: Problem Text and/or Activities)
User email – 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 - <1|2|3|4> 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]
GWD-??
February 2002
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 email as well as reference it prominently near the
top of the response to the problem.
(Every email 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 email 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 email>consult@nkba.edu
<originator ticket>013956
<user email>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]
GWD-??
February 2002
Sandia NM [zip code], USA
ebaldon@sandia.gov
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]
GWD-??
9
February 2002
Appendix A: Sample Representation - XML
E. Baldonado <ebaldon@sandia.gov>
[Page 5]
Download