Age | Commit message (Collapse) | Author | Files | Lines |
|
- fix vertical whitespace
- more consistent function naming
- clean up file writes
- break up some long lines
- typo fixes
- remove duplicate spaces
- unify print's
Change-Id: I5517747ef9f2e39ade7fb553ae2b1547fdf7b9e1
Signed-off-by: Peter Barabas <peter.barabas@ericsson.com>
|
|
Fix typo which result in error while getting default metadata
in case if it's not overridden in scenario.
Fixes https://jira.opnfv.org/browse/FUEL-151
Change-Id: Ibf40f846919155e27da5dc1f778f72afee79ff12
Signed-off-by: Fedor Zhadaev <fzhadaev@mirantis.com>
|
|
|
|
Change-Id: I215da0a101d94e2c3fd4aeea80b98f7c9aefe0fb
Signed-off-by: Peter Barabas <peter.barabas@ericsson.com>
|
|
Change-Id: I306b8260ea37fb32ef8db8cf5d4628b50328027f
Signed-off-by: Peter Barabas <peter.barabas@ericsson.com>
|
|
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
|
|
This reverts commit 0eabb596edefd6562a892f27f4e838d9d21c5243.
Change-Id: Ifc4cb5bd12bdf50f0dd903af66037a428aed0201
|
|
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
|
|
- 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>
|
|
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>
|
|
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>
|