Age | Commit message (Collapse) | Author | Files | Lines |
|
- Added licences and (c) to files not complying to Licence and (c) policies.
- Removed example templates not having correct licence claims and no longer being rellevant.
- Removed the Vagrant deployment method as it is not used, not rebased/up to date and not holding correct license claims.
Strategies used:
- Machine generated are not assigned an licence text, the licence follow from the source.
- Generated patch files are not assigned an licence text, the licence follow from the source.
Change-Id: I9763f076eae51fbb2d4e5cb8cacfa4bb6cf338cc
Signed-off-by: Jonas Bjurel <jonas.bjurel@ericsson.com>
|
|
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>
|
|
intel-sc is the lab devel-pipeline configuration for a lab of Intel
in Santa Clara, CA, USA. This lab is behind Intel proxy sever.
Change-Id: I401b030adf82d6a19397e92aef4b30ebe971d80c
Signed-off-by: davidjchou <david.j.chou@intel.com>
|
|
* increase the memory/cpu of controller for noha case
* reduce the memory of computes
Change-Id: Iea9351bb846823fae64a662e92f894eca2f6cecb
Signed-off-by: Michael Polenchuk <mpolenchuk@mirantis.com>
|
|
It is possible that some one changes the
config of the vms from a virtual environment.
This is already shown in the elx lab.
To make everyone aware of this we push it
to the default lab as well.
Change-Id: I4e9012b3237838b98321472bb16037aa0aeacfdc
Signed-off-by: Nikolas Hermanns <nikolas.hermanns@ericsson.com>
|
|
Functest framework is trying to access internal endpoints from host
level which currently is not possible in virtual deployments. Move mgmt
network to untagged interface and setup IP address from mgmt subnet on
the linux bridge where mgmt traffic is traversing.
There will be corresponding changes in securedlab repository.
JIRA: FUEL-167
Change-Id: I29b8ebb23a64e39a4e56b27639a87ce2386b9774
Signed-off-by: Michal Skalski <mskalski@mirantis.com>
|
|
Change-Id: I9d2fc979886510c165af8dbac93ddcdc954727cf
Signed-off-by: wuwenbin2 <wuwenbin2@huawei.com>
|
|
Minor fix in the ELX version.
Update to Fuel 9.0 in the default version.
Change-Id: Ic084b86e7f6d2dfc3d15b10f0ef72e04ef2b7bf6
Signed-off-by: Stefan K. Berg <stefan.k.berg@ericsson.com>
|
|
Change-Id: I380087889cda079a56c8cea3acc13145dcd49046
Signed-off-by: Stefan K. Berg <stefan.k.berg@ericsson.com>
|
|
This commit enables the full configuration
of the VM(fuel/controller/compute)
defintion through the dha file.
Change-Id: I4e78334d1e5aec1e98667343390283587f0b3ea5
|
|
Some compones of openstack produce a lot of CPU load.
With this commit it is possible to
make more use of the Hypervisor where the virtual
nodes runs on.
Change-Id: Ide567dd0823c5526171c29073f2a36aa5f27d4b6
|
|
Please review this carefully!
Strategy:
1) No strict research on copyright/who did what (if you want it changed
contact the Fuel team or Jonas Bjurel)
2) Licence statements will not be added to the following file types:
- Patch files or orig files for patches
- Config files generated by ordinary tools, like libvirt/visrsh
- GIT dierctive file
- Other auto-generated files
Change-Id: I48504c6f27925445dc44683a27a575bcab78d828
Signed-off-by: Jonas Bjurel <jonas.bjurel@ericsson.com>
|
|
Change-Id: I386113113a7f3d754f66c2a359ef4a5d18176f47
Signed-off-by: Jonas Bjurel <jonas.bjurel@ericsson.com>
|
|
Note:
- Lab configurations removed
- Most of the POD configuration files resides in the securedlab repo
- The securedlab repo is very restricive, cause it carries Lab internal
secrets
TODO:
- Ericsson virt is not yet rebased
- Intel virt is not yet rebased
- LF-POD2 is not yet rebased
- Deployment scenarios for vsperf, NFVOVS, NFVKVM, ONOS, VSPERF, BGPVPN is not yet rebased
NOT VERIFIED
DO NOT MERGE
Change-Id: I59d96acb26c06abf60c254fae8ea2ced332e5884
Signed-off-by: Jonas Bjurel <jonas.bjurel@ericsson.com>
|
|
Change-Id: I47a5e2b3bc0e74c44256c6733e331b89889cf9c7
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>
|