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.
Difference between revisions of "EGI Core activities:2013-bidding Software provisioning infrastructure"
| Line 17: | Line 17: | ||
** Base: contains the packages released in the first major release | ** Base: contains the packages released in the first major release | ||
** Update: contains the packages released in the update releases | ** Update: contains the packages released in the update releases | ||
** Release Candidate: it is generated before a UMD release to test the installability | ** 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. | |||
* Community repositories: through AppDB developers must have access to a repository-as-a-service platform to upload their software release and easily push them in the UMD software provisioning process, if necessary. | |||
* Front-end | * Front-end | ||
Revision as of 13:34, 3 July 2013
Go back to the activity list.
- Service name: Software provisioning infrastructure
- Service category: Software
- Service type: Operation and maintenance
Introduction
The software provisioning infrastructure provides the technical tools to support the UMD release process from pulling packages from the developers repositories to the build of a release.
Technical description
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.
- Bouncer: this tool, starting from the information provided during the submission of the product to UMD, queries the developers repositories as well as the associated operating system add-ons repositories to determine which packages compose the product and must be downloaded into the UMD repositories
- Repositories, the following respositories 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.
- Community repositories: through AppDB developers must have access to a repository-as-a-service platform to upload their software release and easily push them in the UMD software provisioning process, if necessary.
- Front-end
The software provisioning infrastructure must support multiple operating system (SL based, and Debian based) and major releases (at least two major releases).
Operations
Maintenance
Service level targets
Support
The activity must provide support through the dedicated GGUS support unit, during working hours