octopus:brahmaputra_ci_process
Differences
This shows you the differences between two versions of the page.
| Next revision | Previous revision | ||
|
octopus:brahmaputra_ci_process [2015/11/30 16:40] Fatih Degirmenci created |
octopus:brahmaputra_ci_process [2016/01/05 15:21] (current) Fatih Degirmenci |
||
|---|---|---|---|
| Line 9: | Line 9: | ||
| ====== Current CI Process ====== | ====== Current CI Process ====== | ||
| - | As highlighted in the previous section, current CI process is driven by the installers. All installers have daily jobs that run jobs in certain order; build, deploy, and test as shown on below diagram. | + | As highlighted in the previous section, current CI process is driven by the installers. All installers have installer specific daily jobs that run jobs in certain order; build, deploy, and test as shown on below diagram. Build and deploy jobs are also installer specific and test jobs execute same tests for all installers. |
| {{ :octopus:installer_driven_ci.png |}} | {{ :octopus:installer_driven_ci.png |}} | ||
| 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. | + | |
| - | + | ||
| - | 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. | + | |
| - | + | ||
| - | ====== 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 | ? | ? | ? | ? | | + | |
| - | + | ||
| - | + | ||
| - | 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. | + | |
octopus/brahmaputra_ci_process.1448901656.txt.gz · Last modified: 2015/11/30 16:40 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
