aboutsummaryrefslogtreecommitdiffstats
path: root/ci
AgeCommit message (Collapse)AuthorFilesLines
2016-06-08Script to clean expired build cache itemsStefan K. Berg1-0/+38
Change-Id: I5e466c89c05eb4d637778218cfe03b88d569f331 Signed-off-by: Stefan K. Berg <stefan.k.berg@ericsson.com>
2016-04-30deploy.sh: do not expect a parameter for -hJosep Puigdemont1-1/+3
If -h was given as a parameter to the script, it would report an error as it expected a parameter, and if it was called as the only parameter, it would run deploy.py as if "old style" parameters had been given, thus showing the usage for the python script, instead of the expected usage message for this script. Update the usage message to include -h. Change-Id: I0930936962c1cb479ec4409ff114cd60a386b276 Signed-off-by: Josep Puigdemont <josep.puigdemont@enea.com>
2016-03-11small fix for deploy.py invocationSzilard Cserey1-6/+9
Change-Id: I8587500c71f05ca69645422ae110651196e0cad2
2016-03-11Add no_deploy_environment optionNikolas Hermanns1-3/+9
For development reason it is useable to have an option so that everything is done except the deploy of the openstack environment. Change-Id: I1f1b7f9c89ee8c9ceea96353e25a51eee53b955c
2016-01-11Added a few more deply.sh arguments needed by JenkinsJonas Bjurel1-8/+53
Added arguments: -B PXE Bridge for booting of Fuel master -f Deploy on existing Fuel master -F Do only create a Fuel master -H NO Health check -S Storage dir for VM images Added checks for URI formats Change-Id: I1f5138a2058e7b3274e9acf4bbbba243a427fb96 Signed-off-by: Jonas Bjurel <jonas.bjurel@ericsson.com>
2016-01-11Small fixes to the deployment scenario framework:Jonas Bjurel1-18/+27
- Added deploy.sh -d option for dryrun. With -d + all the other mandatory arguments, deploy.sh produces ci/config/dea.yaml and /ci/config/dha.yaml with out actually deploying the stack. - Bugfix to exit with rc <> 0 if deployment fails. - Don't delete the programatically constructed dea.yaml or dha.yaml under fuel/ci/config after deploy has finished. dea.yaml and dha.yaml are needed functest, therefore these files must not be deleted after deployment has finished. They will reside in fuel/ci/config/. - Dont merge the dha-override section in deployment scenarios with the final dha.yaml unless the deployment is virtual. There is no way you can programatically override physicall resources, wireing, ipmi set-up, etc. - while you can for virtual environments. VERIFIED READY TO MERGE Change-Id: If4dedc472e07ed60071ee34c73db29f3b9c45252 Signed-off-by: Jonas Bjurel <jonas.bjurel@ericsson.com>
2016-01-08A simple method to separate configuration for base fuel, plugins, PODsJonas Bjurel2-97/+264
and deployment/test scenarios READY TO MERGE! Replaces: https://gerrit.opnfv.org/gerrit/#/c/3995/ Abstract -------- This deployment framework relies on a configuration structure, providing base installer configuration, per POD specific configuration, plugin configuration, and deployment scenario configuration. - The base installer configuration resembles the least common denominator of all HW/POD environment and deployment scenarios (These configurations are normally carried by the the installer projects in this case (fuel@OPNFV). - Per POD specific configuration specifies POD unique parameters, the POD parameter possible to alter is governed by the Fuel@OPNFV project. - Plugin configuration - providing configuration of a specific plugin. these configurations maintain there own namespace and are normally maintained by collaborative projects building Fuel@OPNFV plugins - Deployment scenario configuration - provides a high level, POD/HW environment independent scenario configuration for a specific deployment. It defines what features/plugins that shall be deployed - as well needed overrides of the plugin config as well as the base installer-, POD/HW environment- configurations. Objects allowed to override is governed by the Fuel@OPNFV project. Executing a deployment ---------------------- deploy.sh must be executed locally at the target lab/pod/jumpserver A lab configuration structure must be provided - see the section below. It is straight forward to execute a deployment task - as an example: sudo deploy.sh -b file:///home/jenkins/config -l ericsson-1 -p pod-2 -s os_odl-l2_no-ha -i file:///home/jenkins/MyIso.iso -b and -i arguments should be expressed in URI style. The resources can thus be local or remote. Feedback -------- Please give feed-back before I'm going to far on a wrong tangent Implemented scenarios so far: ----------------------------- - os_ha - os_no-ha - os_odl-l3_ha - os_odl-l3_no-ha - os_odl-l2_ha - os_odl-l2_no-ha - os_onos_ha - os_onos_no-ha - os_kvm_ha - os_kvm_no-ha - os_ovs_ha - os_ovs_no-ha - os_kvm_ovs_ha - os_kvm_ovs_no-ha VERIFIED READY TO MERGE JIRA: FUEL-35 Change-Id: I94a9b477d8ed4ee8057c16d8f20fe543f7ecc20d Signed-off-by: Jonas Bjurel <jonas.bjurel@ericsson.com>
2015-11-27Restructcture of the directory layoutJonas Bjurel3-0/+383
Restructure of the directory layout due to move of Fuel into it's own repo JIRA: FUEL-85 Change-Id: I3647e1992a508f29dce06a5d6c790725c527f6f5 Signed-off-by: Jonas Bjurel <jonas.bjurel@ericsson.com>