As baseline we use the Request for Change (Jira tickets) created any time the suppliers announce a new release of their services. In the tickets it is reported the date when a given change has been implemented and the version. The links in the table point to the Jira project where the tickets are collected by the "component" field. In the following tables there is a summary on how the attributes are controlled. The changes affecting some of the attributes in the table below are not in the CHM scope because they are controlled in a federated way. For us transparency means either that the information is stored and maintained on GOCDB or that we are notified by email about any change. The associated attributes in the table below are not software-related and they are controlled by the EGI Federation in other ways (infrastructure procedures, management boards, etc.).Baseline
Level of control
List of Software/Hardware attributes
Service Components Attribute... ...under direct EGI Foundation control ...controlled by suppliers, whose changes need the EGI F. approval ...where EGI F. must have transparency Procedure / How it is controlled Type of EGI CHM change Approving body Onezone, Oneprovider Service endpoints 
registered on GOCDB: EGI-DATAHUB Normal EGI CAB Software version Normal/Standard EGI CAB Changes to underlying infrastructure with an impact to the service Normal EGI CAB Service operators (individuals) registered on GOCDB: EGI-DATAHUB Standard provider List of attributes not related to software or hardware
Service component CI/Attribute... ...under direct EGI F. control ...controlled by suppliers, whose changes need the EGI F. approval ...where EGI F. must have transparency Procedure / How it is controlled Approving body Onezone, Oneprovider Service operators (individuals) registered on GOCDB: EGI-DATAHUB provider
Overview
Content Tools