octopus:brahmaputra_ci_process
Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision | |||
|
octopus:brahmaputra_ci_process [2015/12/03 15:02] Fatih Degirmenci |
octopus:brahmaputra_ci_process [2016/01/05 15:21] (current) Fatih Degirmenci |
||
|---|---|---|---|
| Line 27: | Line 27: | ||
| ====== CI Process Proposal for Brahmaputra ====== | ====== CI Process Proposal for Brahmaputra ====== | ||
| - | Due to reasons listed above, OPNFV CI process needs to be improved, separating the installer specific build and deploy from testing. | + | Previous proposal will not be possible to realize due to time and resource constraints so Brahmaputra CI process will be quite same to Arno if not the same. This subject will be revisited after Brahmaputra is released. |
| - | + | ||
| - | This can be achieved by introducing simple promotion mechanism meaning that installer jobs can identify daily stable versions by running build and deploy as necessary, marking the version that is used as stable and exiting. | + | |
| - | + | ||
| - | When it comes to testing focused CI process, the first thing that needs to be done is choosing the stable version of an installer to do the deployment. If there is a more recent stable version then the deployment can use this version to deploy the platform. If the installer(s) are unable to produce recent stable version then the deployment either can be done using the latest known stable version or can be skipped altogether if the test projects leave the SUT as they found it. | + | |
| - | + | ||
| - | The installer part is similar to current CI process; each installers has its own daily, build, and deploy jobs. Once a stable version of installer is determined, the test focused runs will use this stable version and execute same testing against the deployed platform. So testing should be same for all 4 installers. | + | |
| - | + | ||
| - | Below diagram shows this in high level. | + | |
| - | + | ||
| - | {{ :octopus:opnfv_platform_ci.png |}} | + | |
| - | + | ||
| - | Here are the steps. | + | |
| - | + | ||
| - | **installer-daily** | + | |
| - | - **installer-build**: Checkout the latest version of the installer repo, build the ISO, and store the ISO on OPNFV Artifact repository as latest. | + | |
| - | - If installer is not ISO based, this step does not exist. | + | |
| - | - **installer-deploy**: Checkout the latest version of the installer, download the latest ISO and start the deployment. | + | |
| - | - **If the deployment succeeds**: Mark the installer version as stable by placing installer metadata in //stable.properties// file and upload this file to OPNFV Artifact Repository, overwriting the existing stable.properties file. The stable.properties file contains the installer repo SHA1 so non-ISO based installers are also covered. | + | |
| - | - **If the deployment fails**: Do nothing. | + | |
| - | - If installer is not ISO based, the deployment is done using the latest version of the scripts located in installer repo. | + | |
| - | + | ||
| - | **opnfv-daily** | + | |
| - | - **opnfv-installer-deploy**: Fetch the stable.properties and initiate the deployment. | + | |
| - | - If the installer is ISO based, download the stable ISO, checkout the stable version of the installer repo using the SHA1 from stable.properties file and proceed with the deployment. | + | |
| - | - If the installer is not ISO based, just checkout the stable version of the installer repo using the SHA1 from stable.properties file and proceed with the deployment. | + | |
| - | - As noted before, if redeployment is not necessary, this step can totally be skipped. | + | |
| - | - **test-projects**: Run the testing as usual. | + | |
| - | + | ||
| - | Please note that the stability referred here is something that is deployable. There are many details that are not taken into account in this proposal. (such as feature addons and so on) | + | |
| - | + | ||
| - | ====== Resource Needs ====== | + | |
| - | + | ||
| - | As expected, above proposal requires additional resources to be available in order to separate the installer specific CI from the OPNFV Platform CI that is used for testing purposes. Infra and test projects are in an agreement regarding this need and have been raising this issue as a risk to the community. It is important to get approval from TSC in order to use community labs for Brahmaputra Release Testing. | + | |
| - | + | ||
| - | Current planning regarding the resources can be seen on below table. | + | |
| - | + | ||
| - | ^ ISO to Deploy ^Apex ^Compass ^Fuel ^Joid ^ | + | |
| - | ^ Stable | Intel POD2 | Huawei | LF POD2 | Intel POD5 | | + | |
| - | ^ Latest | LF POD1 (?)| Intel POD8 (?)| Ericsson POD (?)| Intel POD6 (?)| | + | |
| - | + | ||
| - | As explained in the proposal, only "stable" version shall be deployed on the target platforms and the Stable row points to target labs to do this. We still need to identify where to run installer specific CI. | + | |
| - | + | ||
| - | Another thing to highlight is that the same tests need to be executed on all PODs, guaranteeing the portability of OPNFV target platform. | + | |
octopus/brahmaputra_ci_process.1449154959.txt.gz · Last modified: 2015/12/03 15:02 by Fatih Degirmenci
Page Tools
Except where otherwise noted, content on this wiki is licensed under the following license: Creative Commons Attribution 4.0 International License
