aboutsummaryrefslogtreecommitdiffstats
path: root/ci
AgeCommit message (Collapse)AuthorFilesLines
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>
assed from the parent template - note if you maintain # out-of-tree templates they may require additional parameters if the # in-tree templates add a new role. parameters: controller_servers: type: json compute_servers: type: json blockstorage_servers: type: json objectstorage_servers: type: json cephstorage_servers: type: json # Note extra parameters can be defined, then passed data via the # environment parameter_defaults, without modifying the parent template resources: CollectMacConfig: type: OS::Heat::SoftwareConfig properties: group: script config: | #!/bin/sh MACS=$(ifconfig | grep ether | awk '{print $2}' | tr "\n" " ") HOSTNAME=$(hostname -s) echo "$HOSTNAME $MACS" # FIXME(shardy): Long term it'd be better if Heat SoftwareDeployments accepted # list instead of a map, then we could join the lists of servers into one # deployment instead of requiring one deployment per-role. CollectMacDeploymentsController: type: OS::Heat::SoftwareDeployments properties: servers: {get_param: controller_servers} config: {get_resource: CollectMacConfig} actions: ['CREATE'] # Only do this on CREATE CollectMacDeploymentsCompute: type: OS::Heat::SoftwareDeployments properties: servers: {get_param: compute_servers} config: {get_resource: CollectMacConfig} actions: ['CREATE'] # Only do this on CREATE CollectMacDeploymentsBlockStorage: type: OS::Heat::SoftwareDeployments properties: servers: {get_param: blockstorage_servers} config: {get_resource: CollectMacConfig} actions: ['CREATE'] # Only do this on CREATE CollectMacDeploymentsObjectStorage: type: OS::Heat::SoftwareDeployments properties: servers: {get_param: objectstorage_servers} config: {get_resource: CollectMacConfig} actions: ['CREATE'] # Only do this on CREATE CollectMacDeploymentsCephStorage: type: OS::Heat::SoftwareDeployments properties: servers: {get_param: cephstorage_servers} config: {get_resource: CollectMacConfig} actions: ['CREATE'] # Only do this on CREATE # Now we distribute all-the-macs to all nodes DistributeMacConfig: type: OS::Heat::SoftwareConfig properties: group: script inputs: - name: controller_mappings - name: compute_mappings - name: blockstorage_mappings - name: objectstorage_mappings - name: cephstorage_mappings config: | #!/bin/sh echo $controller_mappings > /root/controller_mappings echo $compute_mappings > /root/compute_mappings echo $blockstorage_mappings > /root/blockstorage_mappings echo $objectstorage_mappings > /root/objectstorage_mappings echo $cephstorage_mappings > /root/cephstorage_mappings echo "mappings = $(cat /root/*_mappings)" DistributeMacDeploymentsController: type: OS::Heat::SoftwareDeployments properties: servers: {get_param: controller_servers} config: {get_resource: DistributeMacConfig} input_values: # FIXME(shardy): It'd be more convenient if we could join these # items together but because the returned format is a map (not a list) # we can't use list_join or str_replace. Possible Heat TODO. controller_mappings: {get_attr: [CollectMacDeploymentsController, deploy_stdouts]} compute_mappings: {get_attr: [CollectMacDeploymentsCompute, deploy_stdouts]} blockstorage_mappings: {get_attr: [CollectMacDeploymentsBlockStorage, deploy_stdouts]} objectstorage_mappings: {get_attr: [CollectMacDeploymentsObjectStorage, deploy_stdouts]} cephstorage_mappings: {get_attr: [CollectMacDeploymentsCephStorage, deploy_stdouts]} actions: ['CREATE'] # Only do this on CREATE outputs: # This value should change if the configuration data has changed # It is used to e.g re-apply puppet after hieradata values change. config_identifier: value: {get_attr: [DistributeMacDeploymentsController, deploy_stdouts]}