Alert.png 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.

2019-bidding/operations-portal

From EGIWiki
Revision as of 09:46, 13 November 2019 by Catalin (talk | contribs) (Effort EGI vs EOSC)
Jump to navigation Jump to search
Main EGI.eu operations services Support Documentation Tools Activities Performance Technology Catch-all Services Resource Allocation Security


EGI Core services menu: Services PHASE I Services PHASE II Services PHASE III Bids Payments Travel procedure Performance



Go back to the EGI Core Activities Bidding page.

Service name: Operations Portal

Introduction

EGI provides a central portal for the operations community that offers a bundle of different capabilities, such as the broadcast tool, VO management facilities, a security dashboard and an operations dashboard that is used to display information about failing monitoring probes and to open tickets to the Resource Centres affected. The dashboard also supports the central infrastructure oversight activities. It is fully interfaced with the EGI Helpdesk and the monitoring system through messaging.

The Operations Portal is a critical component as it is used by all EGI Operations Centres to provide support to the respective Resource Centres. Moreover, it provides tools supporting security operations, VO management, broadcast, availability reporting.

The Operations Portal includes also a new tool, VAPOR, which displays information gathered by the BDII, among which the amount of resources of the EGI RCs.

Technical description

The Operations Portal provides different capabilities:

  • The detection and the follow-up of incidents on the different resource centre of the EGI infrastructure
  • The repository for the static information related to Virtual Organizations
  • The broadcast tool
  • A visualisation (charts) and notification (emails or rss) system related to the downtimes impacting the services, the sites, the NGIs or the VO
  • A user tracking tool
  • Metrics and charts
  • Aggregation by VO, RC, and OC of the BDII information
    • Several tools to see Glue2 information
    • Detailed information about resources that support a site or a VO
    • Track the storage data by scanning the VOs catalog (detect dark data and lost files)

The architecture is composed of three modules:

  • A database – to store information related to the users or the VO
  • A web module – graphical user interface – which is currently integrated into the Symfony and bootstrap frameworks
  • A Data Aggregation and Unification Service

Different components of the services must be deployed in a high-availability configuration.

Authentication modules have to be integrated with EGI Check-in service.

Coordination

This activity is responsible for the coordination of the system operation and upgrade activities with those partners that are in charge of operating other systems that depend on it. Coordination with the EGI Operations is necessary to support the production of reports and to provide data views not available in the portal standard interfaces.

Operations

  • Daily running of the system
  • Provisioning of a high availability configuration
  • A testing infrastructure to verify interoperability and the impact of software upgrades on depending systems
  • Creating an Availability and Continuity Plan and implementing countermeasures to mitigate the risks defined in the related risk assessment
  • Deployment of the testing and production infrastructures of the developments produced by EGI-Engage

Maintenance

This activity includes:

  • Bug fixing, proactive maintenance, improvement of the system
  • Coordination of software maintenance activities with other technology providers that provide software for the EGI Core Infrastructure or remote systems deployed by integrated and peer infrastructures that interoperate with the Operations Portal.
  • Maintenance of probes to test the functionality of the service
  • Requirements gathering
  • Documentation

Software compliance

  • Unless explicitly agreed, software being used and developed to provide the service should:
    • Be licensed under an open source and permissive license (like MIT, BSD, Apache 2.0...)
      • The license should provide unlimited access rights to the EGI community
    • Have source code publicly available via a public source code repository (if needed a mirror can be put in place under the EGI organisation in GitHub). All releases should be appropriately tagged
    • Adopt best practices:
      • Defining and enforcing code style guidelines
      • Using Semantic Versioning
      • Using a Configuration Management frameworks such as Ansible
      • Taking security aspects into consideration through at every point in time
      • Having automated testing in place
      • Using code reviewing
      • Treating documentation as code
        • Documentation should be available for developers, administrators and end users

IT Service Management compliance

  • Key staff who deliver services should have foundation or basic level ITSM training and certification
    • ITSM training and certification could include FitSM, ITIL, ISO 20000 etc.
  • Key staff and service owners should have advanced/professional training and certification covering the key processes for their services
  • Providers should have mature and well maintained ITSM process that are key to support the services they provide

Support

Support is provided via EGI Service Desk Support Unit: Operations Portal (http://helpdesk.egi.eu/).

Support hours: eight hours a day, Monday to Friday excluding public holidays of the hosting organization.

Service level targets

Minimum availability: 99%

Minimum reliability: 99%

Response to incidents records in GGUS within support hours: Medium (see https://wiki.egi.eu/wiki/FAQ_GGUS-PT-QoS-Levels#Medium_service)

Effort (EGI-related activities)

Bids planning a total effort of 8 Person Months/year (STC) would allow these services and activities to be addressed appropriately. Effort may be provided as part of either the INFRAEOSC-07 and INFRAEOSC-03 projects.

Effort (EOSC-related activities)

Partners are encouraged to submit details of activities and proposed costing of effort for EOSC Hub related activities. This may include activities related to development of new functionality required by EOSC communities (e.g. in the case of Operations portal, this may include new capabilities or tools to better accommodate EOSC Hub specific requirements) in addition to activities delivering services to these communities.