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.). Service component 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 bodyBaseline
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 FTS3 Service endpoints registered on GOCDB: EGI_DATA_TRANSFER Normal EGI CAB Software version Normal/Standard EGI CAB Changes to underlying infrastructure with an impact to the service Normal EGI CAB List of attributes not related to software or hardware
FTS3 Service operators (individuals) registered on GOCDB: CERN-PROD Provider
Overview
Content Tools