Common use of December 2017 Clause in Contracts

December 2017. The Agreement was discussed and approved by the Customer and the Provider [date]. The Agreement extends the Corporate-level EGI Operational Level Agreement1 with following information: 1The Services The Services are defined by the following properties: IT components The software provisioning infrastructure is composed by the following components: Integration with RT, a new product release (the tuple Product, Platform, Architecture) is associated with a RT ticket, which tracks the status of the product in the software provisioning process. Submission of new products with XML. Repository Back-end: responsible unit for handling the movement of packages between repositories, validating the individual product releases submissions, building accumulative as well as per-product YUM/APT repositories (multiple per OS/Arch case) and the other automations needed to perform the UMD operations. It also provide a RESTful API for external integrations (e.g. with the UMD portal/frontend) Composer: a web-based interface for bundling versioned software products that have successfully passed the UMD verification process, into a robust UMD release ready to be deployed either to the production or the candidate repositories. ReleaseXML editor: a web interface to create a new entry in the UMD release process., it is connected with the RT and the bouncer Repositories: the following repositories must be maintained for every operating system and major release supported: Untested: contains the packages to be installed during the verification Testing: contains the packages to be installed during staged rollout Base: contains the packages released in the first major release Update: contains the packages released in the update releases Release Candidate: it is generated before a UMD release, to simulate the production repositories after the UMD release under preparation. This is used to test the installability of the newly released components, as well as the products already in production. The processes to move products between repositories and to create releases must be as automated as possible. The task must provide statistics about the repository usage in terms of downloads, aggregated by packages and time. Front-end, the information about UMD releases (release notes, list of components, configuration) must be available in a web frontend. Note: the architecture of the internal components is not mandatory, but the services provided must be equivalent. The software provisioning infrastructure must support multiple operating system (EL based, and Debian based) and major releases (at least two major releases). The infrastructure should also support a “Preview” repository where products are quickly released without verification; this is not an official UMD repository, but it follows the same procedures and has the same features. Coordination The task must coordinate with the UMD quality assurance task as well as EGI Operations when necessary, and with the AppDB provider to support the community repository. Operation The task must operate all the technical services described before: Repositories (production, testing, untested and RC, community repositories) Repositories back-end (including UMD composer) Web pages (repository front-end, Release XML editor) The task must support the UMD release creation., creating the release candidates and the actual releases. Maintenance Please describe 2Service hours and exceptions As defined in Corporate-level EGI Operational Level Agreement. 3Support As defined in Corporate-level EGI Operational Level Agreement. Support is provided via EGI Service Desk2 Support Unit: EGI Software provisioning supportSoftware repositories Support is available between: Monday and Friday 9:00 and 17:00 ECET/ECEST time This excludes public holidays at the same time in all organizations providing the service.

December 2017. The Agreement was discussed and approved by the Customer and the Provider [date]. The Agreement extends the Corporate-level EGI Operational Level Lever Agreement1 with following information: 1The Services The Services are defined by the following properties: IT components The software provisioning infrastructure is composed by the following components: Integration with RT, a new product release (the tuple Product, Platform, Architecture) is associated with a RT ticket, which tracks the status of the product in the software provisioning process. Submission of new products with XML. Repository Back-end: responsible unit for handling the movement of packages between repositories, validating the individual product releases submissions, building accumulative as well as per-product YUM/APT repositories (multiple per OS/Arch case) and the other automations needed to perform the UMD operations. It also provide a RESTful API for external integrations (e.g. with the UMD portal/frontend) Composer: a web-based interface for bundling versioned software products that have successfully passed the UMD verification process, into a robust UMD release ready to be deployed either to the production or the candidate repositories. ReleaseXML editor: a web interface to create a new entry in the UMD release process., it is connected with the RT and the bouncer Repositories: the following repositories must be maintained for every operating system and major release supported: Untested: contains the packages to be installed during the verification Testing: contains the packages to be installed during staged rollout Base: contains the packages released in the first major release Update: contains the packages released in the update releases Release Candidate: it is generated before a UMD release, to simulate the production repositories after the UMD release under preparation. This is used to test the installability of the newly released components, as well as the products already in production. The processes to move products between repositories and to create releases must be as automated as possible. The task must provide statistics about the repository usage in terms of downloads, aggregated by packages and time. Front-end, the information about UMD releases (release notes, list of components, configuration) must be available in a web frontend. Note: the architecture of the internal components is not mandatory, but the services provided must be equivalent. The software provisioning infrastructure must support multiple operating system (EL based, and Debian based) and major releases (at least two major releases). The infrastructure should also support a “Preview” repository where products are quickly released without verification; this is not an official UMD repository, but it follows the same procedures and has the same features. Coordination The task must coordinate with the UMD quality assurance task as well as EGI Operations when necessary, and with the AppDB provider to support the community repository. Operation The task must operate all the technical services described before: Repositories (production, testing, untested and RC, community repositories) Repositories back-end (including UMD composer) Web pages (repository front-end, Release XML editor) The task must support the UMD release creation., creating the release candidates and the actual releases. Maintenance Please describe 2Service hours and exceptions As defined in Corporate-level EGI Operational Level Lever Agreement. 3Support As defined in Corporate-level EGI Operational Level Lever Agreement. Support is provided via EGI Service Desk2 Support Unit: EGI Software provisioning supportSoftware repositories <specify> Support is available between: Monday and Friday 9:00 and 17:00 ECETCET/ECEST CEST time This excludes public holidays at the same time in all organizations providing the service.

December 2017. The Agreement was discussed and approved by the Customer and the Provider [date]. The Agreement extends the Corporate-level EGI Operational Level Agreement1 with following information: 1The Services The Services are defined by the following properties: IT components The software provisioning infrastructure is composed by the following components: Integration with RT, a new product release (the tuple Product, Platform, Architecture) is associated with a RT ticket, which tracks the status of the product in the software provisioning process. Submission of new products with XML. Repository Back-end: responsible unit for handling the movement of packages between repositories, validating the individual product releases submissions, building accumulative as well as per-product YUM/APT repositories (multiple per OS/Arch case) and the other automations needed to perform the UMD operations. It also provide a RESTful API for external integrations (e.g. with the UMD portal/frontend) Composer: a web-based interface for bundling versioned software products that have successfully passed the UMD verification process, into a robust UMD release ready to be deployed either to the production or the candidate repositories. ReleaseXML editor: a web interface to create a new entry in the UMD release process., it is connected with the RT and the bouncer Repositories: the following repositories must be maintained for every operating system and major release supported: Untested: contains the packages to be installed during the verification Testing: contains the packages to be installed during staged rollout Base: contains the packages released in the first major release Update: contains the packages released in the update releases Release Candidate: it is generated before a UMD release, to simulate the production repositories after the UMD release under preparation. This is used to test the installability of the newly released components, as well as the products already in production. The processes to move products between repositories and to create releases must be as automated as possible. The task must provide statistics about the repository usage in terms of downloads, aggregated by packages and time. Front-end, the information about UMD releases (release notes, list of components, configuration) must be available in a web frontend. Note: the architecture of the internal components is not mandatory, but the services provided must be equivalent. The software provisioning infrastructure must support multiple operating system (EL based, and Debian based) and major releases (at least two major releases). The infrastructure should also support a “Preview” repository where products are quickly released without verification; this is not an official UMD repository, but it follows the same procedures and has the same features. Coordination The task must coordinate with the UMD quality assurance task as well as EGI Operations when necessary, and with the AppDB provider to support the community repository. Operation The task must operate all the technical services described before: Repositories (production, testing, untested and RC, community repositories) Repositories back-end (including UMD composer) Web pages (repository front-end, Release XML editor) The task must support the UMD release creation., creating the release candidates and the actual releases. Maintenance Please describe 2Service hours and exceptions As defined in Corporate-level EGI Operational Level Agreement. 3Support As defined in Corporate-level EGI Operational Level Agreement. Support is provided via EGI Service Desk2 Support Unit: EGI Software provisioning supportSoftware repositories support Support is available between: Monday and Friday 9:00 and 17:00 ECETCET/ECEST CEST time This excludes public holidays at the same time in all organizations providing the service.

December 2017. The Agreement was discussed and approved by the Customer and the Provider [date]. The Agreement extends the Corporate-level EGI Operational Level Lever Agreement1 with following information: 1The Services The Services are defined by the following properties: IT components The software provisioning infrastructure is composed by the following components: Integration with RT, a new product release (the tuple Product, Platform, Architecture) is associated with a RT ticket, which tracks the status of the product in the software provisioning process. Submission of new products with XML. Repository Back-end: responsible unit for handling the movement of packages between repositories, validating the individual product releases submissions, building accumulative as well as per-product YUM/APT repositories (multiple per OS/Arch case) and the other automations needed to perform the UMD operations. It also provide a RESTful API for external integrations (e.g. with the UMD portal/frontend) Composer: a web-based interface for bundling versioned software products that have successfully passed the UMD verification process, into a robust UMD release ready to be deployed either to the production or the candidate repositories. ReleaseXML editor: a web interface to create a new entry in the UMD release process., it is connected with the RT and the bouncer Repositories: the following repositories must be maintained for every operating system and major release supported: Untested: contains the packages to be installed during the verification Testing: contains the packages to be installed during staged rollout Base: contains the packages released in the first major release Update: contains the packages released in the update releases Release Candidate: it is generated before a UMD release, to simulate the production repositories after the UMD release under preparation. This is used to test the installability of the newly released components, as well as the products already in production. The processes to move products between repositories and to create releases must be as automated as possible. The task must provide statistics about the repository usage in terms of downloads, aggregated by packages and time. Front-end, the information about UMD releases (release notes, list of components, configuration) must be available in a web frontend. Note: the architecture of the internal components is not mandatory, but the services provided must be equivalent. The software provisioning infrastructure must support multiple operating system (EL based, and Debian based) and major releases (at least two major releases). The infrastructure should also support a “Preview” repository where products are quickly released without verification; this is not an official UMD repository, but it follows the same procedures and has the same features. Coordination The task must coordinate with the UMD quality assurance task as well as EGI Operations when necessary, and with the AppDB provider to support the community repository. Operation The task must operate all the technical services described before: Repositories (production, testing, untested and RC, community repositories) Repositories back-end (including UMD composer) Web pages (repository front-end, Release XML editor) The task must support the UMD release creation., creating the release candidates and the actual releases. Maintenance Please describe 2Service hours and exceptions As defined in Corporate-level EGI Operational Level Lever Agreement. 3Support As defined in Corporate-level EGI Operational Level Lever Agreement. Support is provided via EGI Service Desk2 Support Unit: EGI Software provisioning supportSoftware repositories support Support is available between: Monday and Friday 9:00 and 17:00 ECETCET/ECEST CEST time This excludes public holidays at the same time in all organizations providing the service.