summaryrefslogtreecommitdiffstats
path: root/deploy/cloud/configure_nodes.py
AgeCommit message (Collapse)AuthorFilesLines
2017-09-03build, deploy: Remove obsolete Fuel@Openstack codeAlexandru Avadanii1-194/+0
JIRA: FUEL-278 Change-Id: I30c04c325de5ac97aee172386de43201988646c5 Signed-off-by: Alexandru Avadanii <Alexandru.Avadanii@enea.com>
2017-01-23Upload interfaces config before attributesMichael Polenchuk1-14/+7
Enable dpdk on an interface before upload specific settings in order to meet the validator requirements. JIRA: FUEL-247 Change-Id: Id1248b391257b07b26edb5630da47f4dcbafb156 Signed-off-by: Michael Polenchuk <mpolenchuk@mirantis.com>
2017-01-12Enable dpdk property on interfaceMichael Polenchuk1-9/+9
Set dpdk property in network attributes since interface_properties have been removed in scope of nics-and-nodes-attributes-via-plugin blueprint. JIRA: FUEL-243 Change-Id: I7873d3a5c738d421f64237ff41d937856012d65a Signed-off-by: Michael Polenchuk <mpolenchuk@mirantis.com>
2016-11-24Remove unused importsPeter Barabas1-1/+0
Change-Id: Icb51f3fdec962c6f92e27e63b57bc30e8e6c75bb Signed-off-by: Peter Barabas <peter.barabas@ericsson.com>
2016-09-16Stop using network transformationMichal Skalski1-16/+44
Due the bug in code we did not apply network transformation to created environments, but still Fuel base on chosen segmentation type and networks to NICs assigment has been generated network schema itself. Since we don't use custom network schema we can remove transformation defintions from dea pod overrides files. However there is a need to configure NIC properties in case of dpdk deployment. JIRA: FUEL-192 Change-Id: Ib7dab4d61910ac8c44b6d91e0c486c9693034823 Signed-off-by: Michal Skalski <mskalski@mirantis.com>
2016-07-22Add ability to override node attributesFedor Zhadaev1-2/+52
Fixes https://jira.opnfv.org/browse/FUEL-152 Change-Id: I444bf3aef54ffd53c53431e2795b11b10545f55f Signed-off-by: Fedor Zhadaev <fzhadaev@mirantis.com>
2016-06-02Download deployment config after modificationPeter Barabas1-0/+6
Modified network or interface configurations were not reflected in the deployment config, resulting in faulty node configurations. Change-Id: I4ca20702c0171e7995f2b4f46317557ec9d5beac Signed-off-by: Peter Barabas <peter.barabas@ericsson.com>
2016-01-08A simple method to separate configuration for base fuel, plugins, PODsJonas Bjurel1-2/+11
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 Bjurel1-0/+109
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>