The wiki is deprecated and due to be decommissioned by the end of September 2022.
The content is being migrated to other supports, new updates will be ignored and lost.
If needed you can get in touch with EGI SDIS team using operations @ egi.eu.
Difference between revisions of "Instructions for centrally-provided services Service Providers"
| Line 31: | Line 31: | ||
= Ongoing activities<br> = | = Ongoing activities<br> = | ||
== Support - incident and requests handling == | == Support - incident and requests handling == | ||
| Line 70: | Line 68: | ||
'''Interactions among between Development teams''' are guaranteed through periodic phone conferences and face to face meetings. A dedicated mailing list is available as well. <br> | '''Interactions among between Development teams''' are guaranteed through periodic phone conferences and face to face meetings. A dedicated mailing list is available as well. <br> | ||
'''Interactions with customers '''are guaranteed through periodic OMB meetings and (where needed) dedicated [[OTAG|Operations Tool Advisory Group]]. The OTAG mandate is to help developers in requirement prioritization and releasing process of operational tools. OTAG provide forums to discuss the tools evolution that meet the expressed needs of the EGI community. It has representation from the all end users groups depending on the tool. | '''Interactions with customers '''are guaranteed through periodic OMB meetings and (where needed) dedicated [[OTAG|Operations Tool Advisory Group]]. The OTAG mandate is to help developers in requirement prioritization and releasing process of operational tools. OTAG provide forums to discuss the tools evolution that meet the expressed needs of the EGI community. It has representation from the all end users groups depending on the tool.<br> | ||
== Monitoring == | == Monitoring == | ||
Development team is responsible for development, maintenence and support for the tool monitoring probes. | Development team is responsible for development, maintenence and support for the tool monitoring probes. | ||
| Line 80: | Line 76: | ||
Availability and reliability thresholdshould be defined with EGI Operations team depending on criticality of the service. | Availability and reliability thresholdshould be defined with EGI Operations team depending on criticality of the service. | ||
== Documentation == | |||
Development team is responsible for creation and maintenance of documentations, instructions and manuals related to the tool in collaboration with EGI Operations team. | |||
== Release Procedure == | == Release Procedure == | ||
<br>Each tool will be released as a standalone package. PTs are autonomous in the development, but the release schedule and roadmap will be discussed and agreed both internally and with other project actors if needed (i.e. SA1). <br>Testing and documenting the released packages are responsibilities of the PTs under the supervision of the activity management. If a new release for an operational tool affects other tools or middleware installed in the production infrastructure, then a test plan will be discussed among the PTs and/or with the SA1 activity. To easy the information exchange and to discuss test plans a release procedure, which is described below and depicted in Figure 2, will be applied by every PT.<br><br><br>[[Image:Ops tool release process.png]]<br><br> <br>Figure 2 - Operational Tools Release Procedure<br><br>When the development of a new release is completed (T0) a first announce is broadcasted to all the PTs and to all the actors that should be involved in the release testing. The announce has to contain release notes, documentation links, a detailed test plan, an indication of the expected release date and all the information needed by the conformance criteria set by the SA2 activity for the software providers of the project. More information on conformance criteria can be found on the project milestone MS503. The expected release date and the kind of testing will depend on each specific release and on its importance. <br>After the T0 announce the testing phase will take place according to the test plan. If a test fails a report will be produced and the release sent back to development to restart the cycle. Tests will include a documentation review and a documentation update if needed. The test phase can be performed internally to the PT if no other tools or services are affected. When all the tests are passed and no more development/testing cycles are needed the testing phase is concluded (T1) and a second release announce will be broadcasted to the consumers of the new release (i.e. SA1) using the communication facilities offered by the Operation Portal. This second announce will contain the actual release date (TR), the release notes, the documentation links and a document describing the testing phase details. The release can result in an immediate installation on the production instances for the centralized tools or will follow a deployment process, with a possible initial testing phase on a selected number of production instances according to the SA1 needs (StagedRollout, for further details refer to the project milestone MS402).<br>Each tool will maintain its own documentation on the web and links to these web pages will be maintained on the project wiki by the activity management in order to have a single access point to all the tools documentation. The activity management will also supervise the need and the editing of cross tools documentation to support the integrated usage of multiple components. | <br>Each tool will be released as a standalone package. | ||
PTs are autonomous in the development, but the release schedule and roadmap will be discussed and agreed both internally and with other project actors if needed (i.e. SA1). <br>Testing and documenting the released packages are responsibilities of the PTs under the supervision of the activity management. If a new release for an operational tool affects other tools or middleware installed in the production infrastructure, then a test plan will be discussed among the PTs and/or with the SA1 activity. To easy the information exchange and to discuss test plans a release procedure, which is described below and depicted in Figure 2, will be applied by every PT.<br><br><br>[[Image:Ops tool release process.png]]<br><br> <br>Figure 2 - Operational Tools Release Procedure<br><br>When the development of a new release is completed (T0) a first announce is broadcasted to all the PTs and to all the actors that should be involved in the release testing. The announce has to contain release notes, documentation links, a detailed test plan, an indication of the expected release date and all the information needed by the conformance criteria set by the SA2 activity for the software providers of the project. More information on conformance criteria can be found on the project milestone MS503. The expected release date and the kind of testing will depend on each specific release and on its importance. <br>After the T0 announce the testing phase will take place according to the test plan. If a test fails a report will be produced and the release sent back to development to restart the cycle. Tests will include a documentation review and a documentation update if needed. The test phase can be performed internally to the PT if no other tools or services are affected. When all the tests are passed and no more development/testing cycles are needed the testing phase is concluded (T1) and a second release announce will be broadcasted to the consumers of the new release (i.e. SA1) using the communication facilities offered by the Operation Portal. This second announce will contain the actual release date (TR), the release notes, the documentation links and a document describing the testing phase details. The release can result in an immediate installation on the production instances for the centralized tools or will follow a deployment process, with a possible initial testing phase on a selected number of production instances according to the SA1 needs (StagedRollout, for further details refer to the project milestone MS402).<br>Each tool will maintain its own documentation on the web and links to these web pages will be maintained on the project wiki by the activity management in order to have a single access point to all the tools documentation. The activity management will also supervise the need and the editing of cross tools documentation to support the integrated usage of multiple components. | |||
== <br><br>Test phase and monitoring the software quality<br> == | == <br><br>Test phase and monitoring the software quality<br> == | ||
| Line 90: | Line 90: | ||
<br>Testing of the released software is a responsibility of the product teams, however the manpower available for each OTPT does not allow for fully independent testing. In almost all PTs the developers act also as testers, even if, when possible, not the same person performs both activities on the same piece of code. To mitigate this situation it will be important for a PT to discuss the testing plan within the whole jra1 activity to agree contribution to testing from other PTs. Moreover in case of major or particularly important releases contribution can also be found outside the activity, mainly inside the operation community.<br>The quality of the operational tools releases will be constantly monitored trough a set of metrics that will include, in example, the number of bugs found in certification and in production, as well as the time needed to fix critical and non critical bugs by each PT. This metrics are currently under definition. If the monitoring activity will show that the software quality of some operational tools needs to be improved it will reported to the projects management and actions will be undertaken in order to strengthen the testing phase, i.e. increase the number of external and independent testers to be found both internally to the partners developing the tools and externally within the community.<br>Given the limited manpower the prioritization work performed by the supervisioning bodies will be particularly important in order not to waste developing and testing efforts. <br> | <br>Testing of the released software is a responsibility of the product teams, however the manpower available for each OTPT does not allow for fully independent testing. In almost all PTs the developers act also as testers, even if, when possible, not the same person performs both activities on the same piece of code. To mitigate this situation it will be important for a PT to discuss the testing plan within the whole jra1 activity to agree contribution to testing from other PTs. Moreover in case of major or particularly important releases contribution can also be found outside the activity, mainly inside the operation community.<br>The quality of the operational tools releases will be constantly monitored trough a set of metrics that will include, in example, the number of bugs found in certification and in production, as well as the time needed to fix critical and non critical bugs by each PT. This metrics are currently under definition. If the monitoring activity will show that the software quality of some operational tools needs to be improved it will reported to the projects management and actions will be undertaken in order to strengthen the testing phase, i.e. increase the number of external and independent testers to be found both internally to the partners developing the tools and externally within the community.<br>Given the limited manpower the prioritization work performed by the supervisioning bodies will be particularly important in order not to waste developing and testing efforts. <br> | ||
<br> | <br> | ||
[[Category:Tools]] | [[Category:Tools]] | ||
Revision as of 17:06, 9 December 2014
| Main | EGI.eu operations services | Support | Documentation | Tools | Activities | Performance | Technology | Catch-all Services | Resource Allocation | Security |
| Tools menu: | • Main page | • Instructions for developers | • AAI Proxy | • Accounting Portal | • Accounting Repository | • AppDB | • ARGO | • GGUS | • GOCDB |
| • Message brokers | • Licenses | • OTAGs | • Operations Portal | • Perun | • EGI Collaboration tools | • LToS | • EGI Workload Manager |
 This page is under construction.
|
Initial actvities
Every new operations tool developed needs to contact EGI Operations (operations@egi.eu) and provide following data:
- Name of the tool
- Support email
- Name and contact detials of Tool Team leader
- Description of the tool - purpose
With EGI Operations team help following steps needs to be performed
- Creation of url in egi.eu domain
- Registraion in GOC DB under EGI.eu NGI
- Create category in "Requirements" queue in EGI RT tracker and RT dashboard to receive and handle service requestes
- Create GGUS Support Unit to receive and handle incidents (define level of quality of support - default: Medium)
- Negotiate and sign OLA with EGI.eu
- Create wiki entry for the tool with relevant information
- Release schedule
- Release notes
- Roadmap
- link to related OLA
- link to test instance
- link to EGI RT dashboard for the tool
- other: internal bug/task tracking facilities
Ongoing activities
Support - incident and requests handling
Support should be provided:
- via the GGUS portal, which is the single point of contact for infrastructure users to access the EGI Service Desk.
- (for incidents) According to declared level of quality of support (default: Medium)
- Support is provided in English
- Support is available
- Monday and Friday
- 8 h per day
- All incidents and requests should be classified and prioritized according to suitable scheme.
Planned maintenance windows or interruptions
Planned maintenance should be
- declared in GOC DB in a timely manner i.e. 24 hours before
- with typical duration up to 24 hours otherwise needs to be justified
Unscheduled interruptions should be managed according to MAN04
Security
The following rules for information security and data protection apply:
• The Provider must define and abide by an information security and data protection policy related to the service being provided.
• This must meet all requirements of any relevant EGI policies or procedures and also must be compliant with the relevant national legislation.
Interactions
Development team need to interact with each other inside EGI activities, primarily with OMB, the main customer of the operational tools.
Interactions among between Development teams are guaranteed through periodic phone conferences and face to face meetings. A dedicated mailing list is available as well.
Interactions with customers are guaranteed through periodic OMB meetings and (where needed) dedicated Operations Tool Advisory Group. The OTAG mandate is to help developers in requirement prioritization and releasing process of operational tools. OTAG provide forums to discuss the tools evolution that meet the expressed needs of the EGI community. It has representation from the all end users groups depending on the tool.
Monitoring
Development team is responsible for development, maintenence and support for the tool monitoring probes.
Availability and reliability thresholdshould be defined with EGI Operations team depending on criticality of the service.
Documentation
Development team is responsible for creation and maintenance of documentations, instructions and manuals related to the tool in collaboration with EGI Operations team.
Release Procedure
Each tool will be released as a standalone package.
PTs are autonomous in the development, but the release schedule and roadmap will be discussed and agreed both internally and with other project actors if needed (i.e. SA1).
Testing and documenting the released packages are responsibilities of the PTs under the supervision of the activity management. If a new release for an operational tool affects other tools or middleware installed in the production infrastructure, then a test plan will be discussed among the PTs and/or with the SA1 activity. To easy the information exchange and to discuss test plans a release procedure, which is described below and depicted in Figure 2, will be applied by every PT.
Figure 2 - Operational Tools Release Procedure
When the development of a new release is completed (T0) a first announce is broadcasted to all the PTs and to all the actors that should be involved in the release testing. The announce has to contain release notes, documentation links, a detailed test plan, an indication of the expected release date and all the information needed by the conformance criteria set by the SA2 activity for the software providers of the project. More information on conformance criteria can be found on the project milestone MS503. The expected release date and the kind of testing will depend on each specific release and on its importance.
After the T0 announce the testing phase will take place according to the test plan. If a test fails a report will be produced and the release sent back to development to restart the cycle. Tests will include a documentation review and a documentation update if needed. The test phase can be performed internally to the PT if no other tools or services are affected. When all the tests are passed and no more development/testing cycles are needed the testing phase is concluded (T1) and a second release announce will be broadcasted to the consumers of the new release (i.e. SA1) using the communication facilities offered by the Operation Portal. This second announce will contain the actual release date (TR), the release notes, the documentation links and a document describing the testing phase details. The release can result in an immediate installation on the production instances for the centralized tools or will follow a deployment process, with a possible initial testing phase on a selected number of production instances according to the SA1 needs (StagedRollout, for further details refer to the project milestone MS402).
Each tool will maintain its own documentation on the web and links to these web pages will be maintained on the project wiki by the activity management in order to have a single access point to all the tools documentation. The activity management will also supervise the need and the editing of cross tools documentation to support the integrated usage of multiple components.
Test phase and monitoring the software quality
Testing of the released software is a responsibility of the product teams, however the manpower available for each OTPT does not allow for fully independent testing. In almost all PTs the developers act also as testers, even if, when possible, not the same person performs both activities on the same piece of code. To mitigate this situation it will be important for a PT to discuss the testing plan within the whole jra1 activity to agree contribution to testing from other PTs. Moreover in case of major or particularly important releases contribution can also be found outside the activity, mainly inside the operation community.
The quality of the operational tools releases will be constantly monitored trough a set of metrics that will include, in example, the number of bugs found in certification and in production, as well as the time needed to fix critical and non critical bugs by each PT. This metrics are currently under definition. If the monitoring activity will show that the software quality of some operational tools needs to be improved it will reported to the projects management and actions will be undertaken in order to strengthen the testing phase, i.e. increase the number of external and independent testers to be found both internally to the partners developing the tools and externally within the community.
Given the limited manpower the prioritization work performed by the supervisioning bodies will be particularly important in order not to waste developing and testing efforts.