EGI Foundation Operations and Process Alignment for Effective Research Computing

egi advanced computing for research n.w
1 / 11
Embed
Share

Discover how the EGI Foundation, partly funded by the European Commission, enhances operational processes such as Configuration Management, Change Management, and Release and Deployment Management for improved research computing efficiency. Explore the alignment aims, service components, and control levels within the organization's infrastructure.

  • EGI Foundation
  • Research Computing
  • Process Alignment
  • Configuration Management
  • Change Management

Uploaded on | 0 Views


Download Presentation

Please find below an Image/Link to download the presentation.

The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author. If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.

You are allowed to download the files provided on this website for personal or commercial use, subject to the condition that they are used lawfully. All files are the property of their respective owners.

The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author.

E N D

Presentation Transcript


  1. EGI: Advanced Computing for Research www.egi.eu @EGI_eInfra CONFM/CHM/RDM Process Alignment Matthew Viljoen, Operations Manager EGI Foundation The work of the EGI Foundation is partly funded by the European Commission under H2020 Framework Programme

  2. Project News Configuration Management (CONFM), Change Management (CHM), Release and Deployment Management (RDM) Process Alignment Aims: Improve ease of use of these operational processes Moved processes to publicly accessible Conflunce pages EGI Policies and Procedures home (part of MediaWiki deprecation) Defined set of Configuration Items (Cis) under CONFM, along with responsibility Adoption of Jira for CHM Clearer link between CHM and RDM Process pages: CONFM: https://ims.egi.eu/display/EGIPP/EGI+Configuration+Management+CONFM CHM: https://ims.egi.eu/display/EGIPP/EGI+Change+Management+CHM RDM: https://ims.egi.eu/display/EGIPP/EGI+Release+and+Deployment+Management+RDM www.egi.eu @EGI_eInfra 2 16/06/2025

  3. CONFM (I) CMDB, Cis, and level of control Most of the services we are offering are actually not under direct control of EGI Foundation because they are operated by EGI Federation members according to the several OLAs/Uas important to understand what we can control, what we have to control, what we have to be made aware of but we don't have to control Service Components and Cis categorised based on the level of control Service components and CIs under direct / full control of EGI Foundation CIs controlled by suppliers, whose changes need the EGI Foundation approval Service components and CIs with transparency for EGI Foundation (controlled by supplier / federation member) CMDB composed by GOCDB, Internal CMDB, and Information System www.egi.eu @EGI_eInfra 3 16/06/2025

  4. CONFM (II) Internal CMDB Each entry of the internal CMDB is de facto a configuration item and contains: a list of attributes related to the given CI (first table in the page) a link to the baseline a list of associated attributes/CIs/CIs types (second table in the page) For the several attributes it is also reported the following information: if there is a specific "infrastructure" procedure controlling it where they are stored the type of change, useful to say if invoking the CAB is necessary or not who is the approving body: o many CIs are managed on a federated/infrastructure level (i.e. OMB, EGI Operations, etc.) as described in the related procedure(s) so that the "classic" EGI CAB is expected to be invoked only in a few cases The changes to the attributes whose approving body is the EGI CAB need to be tracked with CHM Jira tickets These tickets represent our baseline for the affected CIs since they include the date when the change has been implemented and the version of the affected CIs (mostly the release version) www.egi.eu @EGI_eInfra 4 16/06/2025

  5. CHM - Main changes from previous procedure CHM Policy has been updated to clarify the services in scope Changes covered under the scope (Major changes) CHM1 was corrected to not allow the Change Requester is the one to approve the change. New role has been created, Change Owner, who approves the change. Change Requester and Change Owner NEVER are the same person. Revised the workflow between CHM and RDM processes Use now a common Jira www.egi.eu @EGI_eInfra 5 16/06/2025

  6. RDM1 - Emergency Release Process Release of one product, or a set of products, to solve a specific problem that affects the EGI infrastructure. Problem has to be one of: A critical security patch A critical bug affecting multiple resource centres www.egi.eu @EGI_eInfra 6 16/06/2025

  7. RDM2 - Regular Release Process Releases of the centrally-provided production services that need to be fully built, tested and deployed. May be either: a high risk/impact change needing careful testing a set of linked changes to test and deploy together lower priority changes bundled together to reduce downtime. www.egi.eu @EGI_eInfra 7 16/06/2025

  8. RDM3 - Lightweight Release Process Applies to individual low risk/impact change and provides steps for service updates and releases. Notes One Jira ticket per change is used to orchestrate the release and deployment In addition a GGUS ticket is used for regular releases (RDM2) - to allow anyone testing and providing feedback during the testing phase www.egi.eu @EGI_eInfra 8 16/06/2025

  9. Extra slides www.egi.eu @EGI_eInfra 9 16/06/2025

  10. CHM Process Scope and Policy All changes MUST follow a process AND ensure PLANNING -> RESOURCING -> EXECUTION Created by Change Requester (service Supplier) Approved by Change Owner (CAB member/service Owner) Normal CH CHM PM CAB CIs Created by Change Requester (service Supplier) Approved by Change Owner (CAB member/service Owner) Standard CH Internal CMDB Created by Change Requester (service Supplier) or EGI Foundation staff Assessed and Approved by Change Owner (without prior CAB approva) Emergency CH Scope Policy www.egi.eu @EGI_eInfra 10 16/06/2025

  11. Release and Deployment Management Goal To plan and oversee the implementation of approved Changes into production. Scope Applies exclusively to all EGI branded services in the service catalogue of EGI Foundation (that are not in the EOSC Hub portfolio). It consists of 3 new procedures that replace the old PROC23 www.egi.eu @EGI_eInfra 11 16/06/2025

Related


More Related Content