summaryrefslogtreecommitdiffstats
path: root/deploy/deploy-config.py
AgeCommit message (Collapse)AuthorFilesLines
2016-04-08Merge "Remove duplicate import of hashlib"Jonas Bjurel1-1/+0
2016-04-07Fix wrong indentationPeter Barabas1-2/+2
Change-Id: I215da0a101d94e2c3fd4aeea80b98f7c9aefe0fb Signed-off-by: Peter Barabas <peter.barabas@ericsson.com>
2016-04-07Remove duplicate import of hashlibPeter Barabas1-1/+0
Change-Id: I306b8260ea37fb32ef8db8cf5d4628b50328027f Signed-off-by: Peter Barabas <peter.barabas@ericsson.com>
2016-04-05Enable merge of the versions struct of a pluginNikolas Hermanns1-3/+48
Redoing this the reverted patch. The original idea that everyone which wants to merge lists has to code that, is not wanted. So the Exception will become a warning. This reverts commit 552536f5319d6ead73118d0cfd701d648e99df28. Change-Id: Ib15541199054da27c1a2aec68b5c1436da9622c9
2016-03-15Revert "Enable merge of the versions struct of a plugin"Jonas Bjurel1-40/+3
This reverts commit 0eabb596edefd6562a892f27f4e838d9d21c5243. Change-Id: Ifc4cb5bd12bdf50f0dd903af66037a428aed0201
2016-03-10Enable merge of the versions struct of a pluginNikolas Hermanns1-3/+40
When the dic of a plugin is not fully merged into the final dea file. When a list contains dicts there is no merge. This commit enables the versions list to be merged. Change-Id: I20ff7bec74f8f71a8cd21010f44715953cd4616d
2016-01-11Small fixes to the deployment scenario framework:Jonas Bjurel1-1/+5
- 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-10ONOS scenario according to wanted config file structureJonas Bjurel1-1/+1
Replaces: - https://gerrit.opnfv.org/gerrit/#/c/5999/ - https://gerrit.opnfv.org/gerrit/#/c/6003/ Description: - Onos scenarios updated with needed dea and dha overrides, no scenario specific information in other config files such dha, dea_base, dea_pod override, etc. - Added a virtual POD for Huawei-china specific needs, i.e. DNS and NTP. - Small fix in deploy-conf.py Change-Id: I85fe2fc4e9ec5fe0bc98ae7b399f2e49af6450f9 Signed-off-by: Jonas Bjurel <jonas.bjurel@ericsson.com>
2016-01-08A simple method to separate configuration for base fuel, plugins, PODsJonas Bjurel1-0/+296
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>