Instructions for centrally-provided services Service Providers

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.

Introducing new Operations Tool Product Team

Every new operations tool developed needs to contact EGI Operations (operations@egi.eu) and provide following data:

1. Name of the tool
2. Support email
3. Name and contact detials of Tool Team leader
4. Description of the tool - purpose

With EGI Operations team help following steps needs to be performed

1. Creation of url in egi.eu domain
2. Registraion in GOC DB under EGI.eu NGI
3. Negotiate and sign OLA with EGI.eu

to define

• Bug/task tracking facilities
• Internal communication channe
• Support communication channels
  
• declare quality of support
• add category in requirements RT tracker and create RT dashboard
• Test instance url
• decide on Ava/rel threshold defined with EGI Operations
• set up wiki page with Release schedule,  Release notes, Roadmap,  Related OLA,
  

• Develop monitoring probe

Support - incident handling

• accordint to declared quality of support
• Support is provided in following language: English
• create GGUS SU
• Monday and Friday
• 8 h per day

Support is provided via the GGUS portal [GGUS], which is the single point of contact for infrastructure users to access the EGI Service Desk. The EGI Service Desk within GGUS is organized in Support Units. Every Support Unit is responsible for one or more services. The number and definition of the EGI Support Units in GGUS is not regulated by this OLA and can change at any time to fulfil the EGI Incident and Problem Management requirements.

Planed maintenance windows or interruptions

Downtime in GOC DB

To be communicated in a timely manner i.e. 24 hours before, to the Customer through the Broadcast Tool [BT]. Typical duration is up to 24 hours otherwise needs to be justified.

This manual provides information on how to manage central operational tool unscheduled downtimes.

https://wiki.egi.eu/wiki/MAN04_Tool_Intervention_Management

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 [POL] and also must be compliant with the relevant national legislation.

Interactions with customers

OTPTs need to interact with each other inside the activity, as well as with other project activities, primarily with SA1,the main customer of the operational tools.
Interactions among OTPTs is guaranteed by the activity management through periodic phone conferences and face to face meetings. Activity progress will be tracked using EGI.eu facilities such as the RT system [31], and will be reported in periodic reports. A dedicated mailing list (under the egi.eu domain) is available for activity as well.
Interaction with external bodies is fundamental in order to get input, feedback and new requirements for the developed tools. Two advisory groups are foreseen by the project description of work: the Operational Tools Advisory Group (OTAG) and the User Services Advisory Group (USAG):
-    Being composed by representatives from the operation community, from the middleware developers and from the JRA1 activity, the OTAG will be the main supervisory group for the development progress and the place where technical discussion about the evolution of the tools will take place
-    The USAG has representatives from the EGI user communities and will focus on the requirements for the complete set of services run by the project but could also impact on the operational tools -  for example end user requirements could be addressed to the GGUS Helpdesk
In order to create the proper schedule for the development it will be important that the outcome of the advisory groups will be a single prioritized table. The prioritization is an important step and possible conflicts should be resolved when multiple requirements from different groups impact the same tool. This is not expected to happen frequently and will be analyzed case by case by the management of the activity together with the advisory groups, possibly escalating the problems to the Activity Management Board if needed.
The development progress of new features, requested and approved by the advisory groups, will be tracked using the project tracking system [31].
The representation of the activity within other project bodies and the reporting on the status of the activity is a responsibility of the activity manager.

request OTAG is needed https://wiki.egi.eu/wiki/OTAG- The OTAG mandate is to help developers in requirment prioritatization 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.

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.   

Develop monitoring probe