Tickets are submitted to the attention of the CHM staff and CAB via Jira, as documented in the procedure CHM1.Required information is as follows:
Summary* | A one-line summary of what the change is. Where possible a unique title. Eg: Update GOCDB to version 2.3. |
Reporter* | Who initiated a request for this change. |
Component/s* | Drop down list of components under scope of CHM |
Attachment | Any relevant attachment to be included in the Request for Change |
A brief summary of what the reason/purpose of the change is. What is being changed and why we need to make the change. It can explain what the benefits of making the change are and/or conversely the consequence of not making the change (For example, the user community needing new functionality or developers with stability improvements.). This is NOT a detailed description of how the change will be implemented. Other relevant information can be: How long will the change take to carry out from start to finish? Will the change require downtime, can it be done transparently. Do you recommend an at-risk? Will end-users need to change their software or working habits? Will external APIs change? Will we need to make changes to internal working practices? When does the change need to be implemented? It enables the CAB to prioritise urgent changes. Give guidance as to how soon this change needs to be scheduled. | |
Assignee | What consultation has already taken place with the user community, what conclusions were reached? |
| Risk impact* | Risk Impact according to CHM Risks. Drop down list: Minor, Moderate, Major, Catastrophic, Unknown |
| Risk likelihood* | Risk Likelihood according to CHM Risks. Drop down list: Unlikely, Possible, Likely, Almost Certain, Unknown |
| Risk level* | Risk Level according to CHM Risks. Drop down list: Low, Medium, High, Extreme, Unknown |
| Type of change* | Drop down list: Normal, Standard, Emergency |
| Does the change affect other EGI services?* | Whether there is potential to effect other EGI services, e.g. due to an API change. Drop down list: Yes, No |
| List other services affected if applicable | If the previous answer is Yes, list the affected services |
| Expected starting date* | Date when it is desired for the intervention to start |
| Downtime Type | Type of downtime that will be declared to the users of the service via GOCDB - if required. Drop down list: Outage, Warning, Not necessary |
Is rollback possible?* | If rollback to the state before the change is possible after implementation of the change. Please provide details in the Description. Drop down list: Yes, No |
[1] It may be useful to use the below template in the 'Description' field of the CHM Jira ticket
Suggested deployment date
<day and time>
Expected downtime: <duration>
Basic Information
| Title | |
|---|---|
| Requested by | |
| Summary |
|
| Urgency | Normal | Urgent |
| Impact of successfully implementing the change |
Likelihood of Problems Occurring
| Details of testing carried out | <If the changes have been tested locally, if deployed and tested in a test/preproduction instance, if production data have been used, etc…> |
|---|---|
| Further tests required prior to implementation | |
| Deployed/tested at other infrastructures? | |
| Can be phased in stages | |
| Implementation plan | 1. ... 2. ... |
| Post-implementation testing | |
| Reversion plan in case of problems |