abe9fbd877
Issue: At AT&T we have large complex test stacks that make putting
everything into a single heat template and environment file very
cumbersome. Large monolithic templates make it harder to debug failures,
maintain, extend, and organize these tests. In order to solve this issue
we have enhanced Shaker to support specifying support templates with
environment files.
This commit enhances Shaker to add the ability to define
support_templates with env_files in test definitions.
Support templates spin up "support type" resources before the actual
test stack is spun up. This could range from networks, to volumes, to
anything Heat can create. The support resources do not have any reliance
on resources created in the test stack, they set up a "foundation" for
the test stack. The test stack can then reference these resources by
name. (e.g. assume they exist by the time the test stack is spun up)
While the example provided with this commit is simple, and the support
networks that get created are not directly used in the test, it
shows the basic principles of how support templates work.
As a real-world example and to give an idea of the complexity this
enhancement is trying to solve, we have a test definition that looks
like this:
support_templates:
-
Base:
template: templates/module_1_base.yaml
env_file: env/module_1_base.env
-
SI_L2:
template: templates/module_2_si_l2.yaml
env_file: env/module_2_si_l2.env
-
SI_L3:
template: templates/module_3_si_l3.yaml
env_file: env/module_3_si_l3.env
template: templates/module_4_master_servant.yaml
env_file: env/module_4_master_servant.env
The first support stack (module_1) sets up some "base" network
resources. This stack provides some network resources used by the SI_L2
and SI_L3 support stacks.
SI_L2 is a support stack with 2 VMs that do Contrail service chaining
on an L2 network.
SI_L3 is a support stack with 2 VMs that do Contrail service chaining
on an L3 network.
Then the test stack (module 4) gets spun up on N amount of computes and
runs traffic across the SI_L2 and SI_L3 service chained networks.
After the test run all stacks are cleaned up
Using the concept of support stacks allows us to beter organize and
maintain our complex tests and allows for faster debugging due to the
"layered" nature of the setup.
Support templates also allow us to spin up more Shaker test threads
that use the same support templates simultaneously to better simulate
real-world network traffic. It also reduces the set up time of certain
tests we have since the support stacks already exist.
This enhancement does not alter existing Shaker functionality and
is fully backwards compatible.
Change-Id: Ife51bc55874c6ec4faac221bab8f9f0eea175fdc
29 lines
993 B
Plaintext
29 lines
993 B
Plaintext
# The order of packages is significant, because pip processes them in the order
|
|
# of appearance. Changing the order has an impact on the overall integration
|
|
# process, which may cause wedges in the gate later.
|
|
|
|
pbr>=1.8 # Apache-2.0
|
|
|
|
diskimage-builder>=1.1.2,!=1.6.0,!=1.7.0,!=1.7.1 # Apache-2.0
|
|
iso8601>=0.1.11 # MIT
|
|
Jinja2!=2.9.0,!=2.9.1,!=2.9.2,!=2.9.3,!=2.9.4,>=2.8 # BSD License (3 clause)
|
|
keystoneauth1>=2.18.0 # Apache-2.0
|
|
os-client-config>=1.22.0,<1.31.0 # Apache-2.0
|
|
oslo.concurrency>=3.8.0 # Apache-2.0
|
|
oslo.config!=3.18.0,>=3.14.0 # Apache-2.0
|
|
oslo.i18n>=2.1.0 # Apache-2.0
|
|
oslo.log>=3.11.0 # Apache-2.0
|
|
oslo.serialization>=1.10.0 # Apache-2.0
|
|
oslo.utils>=3.18.0 # Apache-2.0
|
|
pygal
|
|
pykwalify
|
|
python-glanceclient>=2.5.0 # Apache-2.0
|
|
python-neutronclient>=5.1.0 # Apache-2.0
|
|
python-novaclient>=7.1.0 # Apache-2.0
|
|
python-heatclient>=1.6.1 # Apache-2.0
|
|
python-subunit>=0.0.18 # Apache-2.0/BSD
|
|
PyYAML>=3.10.0 # MIT
|
|
pyzmq>=16.0 # LGPL+BSD
|
|
six>=1.9.0 # MIT
|
|
timeout-decorator>=0.4.0 # MIT
|