| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Make a reboot of the compute nodes to activate hugepages support
and re-apply required states then. Also align ovs lcore & pmd
masks with two cpu nodes.
Change-Id: I4a5defe6f08e912aba2d939ba5ba057af768a40c
Signed-off-by: Michael Polenchuk <mpolenchuk@mirantis.com>
|
|
Change-Id: Ifd6d61026a0e98e8faf59c7d218333122d70ffe9
Signed-off-by: Michael Polenchuk <mpolenchuk@mirantis.com>
|
|
* add/unify ssh options
* get base image to temporary directory
* specify os type for virt install
* fix symbolic link to reclass
* remove outdated fuel submodules
Change-Id: I6833ce78c8fff97e1b89f4e92e6e6b470e9ce99f
Signed-off-by: Michael Polenchuk <mpolenchuk@mirantis.com>
|
|
Change-Id: I7d2af958e447a5892f7cd1f6c6fb8616951e2ff3
Signed-off-by: Michael Polenchuk <mpolenchuk@mirantis.com>
|
|
|
|
Signed-off-by: Alexandru Avadanii <Alexandru.Avadanii@enea.com>
|
|
Original work by Josep, signed by me (Alex) for upstreaming only.
Change-Id: I58a7b9bc639bb03b994ea34fc317f5679140d9fd
Signed-off-by: Josep Puigdemont <josep.puigdemont@enea.com>
Signed-off-by: Alexandru Avadanii <Alexandru.Avadanii@enea.com>
|
|
deploy.py:
Some Fuel VMs may need more than one network interface. To be able to
provide that, we now allow the user to specify the "-b" paramter
(bridge) multiple times, creating a new NIC for each one of them.
The NICs are created in the same order as they are given in the command
line.
There is no change in behavior from earlier versions, pxebr will still
be the default bridge if none is specified in the command line.
deploy.sh:
To reflect the new capabilities of deploy.py, we introduce the
possibility to specify -B more than once in deploy.sh, and honor that
when calling deploy.py. We also make it possible to specify a comma
separated list of bridges, as in: -B br1,br2.
Change-Id: I1a0100f2cfe755ec6adfeedafb391c2357f46f51
Signed-off-by: Josep Puigdemont <josep.puigdemont@enea.com>
|
|
The purpose of this patch is to collect all available Fuel snapshots- and
stack/node ldeployment logs for later off-line troubleshooting.
The intention is that Jenkins, or other deployment robots will be able to
collect all logs from the deployment and store it at some repository where
developers can fetch it and perform off-line post deployment trouble-shooting.
Following script arguments have been added:
CI Arg changes:
Added an argument to ci/deploy.sh:
-L [Deploy log path and file name], E.g.
-L ~/jenkins/deploy/deploy-888.log.tar.gz
This will create an tar gzip archive at the path and filename pointed out.
If -L is not specified, the log archive will be placed under the CI directory
with the following name convention: deploy-YYMMDD-HHMMSS.log.tar.gz
Fuel Internal deploy changes:
Added an argument to ci/deploy.py
-log [Deploy log path and file name], E.g.
-log ~/jenkins/deploy/deploy-888.log.tar.gz
This will create an tar gzip archive at the path and filename pointed out.
If -log is not specified, the log archive will be placed under the CI
directory with the following name convention:
deploy-YYMMDD-HHMMSS.log.tar.gz
READY TO MERGE!
VERIFIED!
Change-Id: Icb75d9d2e66bdd47f75dcca29071943444d5c823
Signed-off-by: Jonas Bjurel <jonas.bjurel@ericsson.com>
|
|
Change-Id: I5e466c89c05eb4d637778218cfe03b88d569f331
Signed-off-by: Stefan K. Berg <stefan.k.berg@ericsson.com>
|
|
If -h was given as a parameter to the script, it would report an error
as it expected a parameter, and if it was called as the only parameter,
it would run deploy.py as if "old style" parameters had been given, thus
showing the usage for the python script, instead of the expected usage
message for this script.
Update the usage message to include -h.
Change-Id: I0930936962c1cb479ec4409ff114cd60a386b276
Signed-off-by: Josep Puigdemont <josep.puigdemont@enea.com>
|
|
Change-Id: I8587500c71f05ca69645422ae110651196e0cad2
|
|
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
|
|
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>
|
|
- 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>
|
|
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>
|
|
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>
|
Michael Polenchuk
Jonas Bjurel
Alexandru Avadanii
Josep Puigdemont
Stefan K. Berg
Szilard Cserey
Nikolas Hermanns