Create a tox environment for running the unit tests against the lower
bounds of the dependencies.
Create a lower-constraints.txt to be used to enforce the lower bounds
in those tests.
Add openstack-tox-lower-constraints job to the zuul configuration.
See http://lists.openstack.org/pipermail/openstack-dev/2018-March/128352.html
for more details.
Change-Id: I67d2ab519d1baf463e4ad253b8a85b5194ad31f6
Depends-On: https://review.openstack.org/555034
Signed-off-by: Doug Hellmann <doug@doughellmann.com>
This uses the -c parameter to process-templates.py to clean the
generated templates in the local repo.
Change-Id: Ib105f60a1e54a6d6372d00bb2db6a9b378b2176e
'pip install -U' ugrades specified packages, this is not necessary
since we use constraints, remove the parameter '-U' from the line.
With tools/tox_install.sh - which a previous change of mine removed -
the -U was not harmful, but with the current set up, it might cause
upgrades, so remove it.
Change-Id: I18b21a396b8df4224cb21ce5b8fd062f80604167
We do not need tox_install.sh, pip can handle constraints itself
and install the project correctly. Thus update tox.ini and remove
the now obsolete tools/tox_install.sh file.
This follows https://review.openstack.org/#/c/508061 to remove
tools/tox_install.sh.
Change-Id: I0b36f95fa92f15159156815bc6d8e1add8902182
The roles data validation added in
2eb1476b6e93279d4ee4988c856dba50ab168bc5 was never run due to a typo in
tox.ini.
Change-Id: I0a151c9863086e4447cedf0790a9e4a18f433cfe
Closes-Bug: #1718391
This check ensures that if a parameter is changed that would affect
a generated environment then the environment must be updated before
pep8 will pass. It will also catch any mistaken hand edits to the
generated files.
bp generated-environments
Change-Id: I2d12992ed55f963285422e1282a4cee06e989b6d
With the merging of Iad3e9b215c6f21ba761c8360bb7ed531e34520e6 the
roles_data.yaml should be generated with tripleoclient rather than
edited. This change adds in a pep8 task to verify that the appropriate
role files in roles/ have been modified to match how our default
roles_data.yaml is constructed. Additionally this change adds a new tox
target called 'genrolesdata' that will all you to automatically generate
roles_data.yaml and roles_data_undercloud.yaml
Change-Id: I5eb15443a131a122d1a4abf6fc15a3ac3e15941b
Related-Blueprint: example-custom-role-environments
We're not going to want to list every single sample environment in
a single file, so let's also take a directory and just read every
yaml file in it. This commit adds support for that as well as
some initial environments to demonstrate its use.
Change-Id: If2c608f2a61fc5e16784ab594d23f1fa335e1d3c
This is a tool to automate the generation of our sample environment
files. It takes a yaml file as input, and based on the environments
defined in that file generates a number of sample environment files
from the parameters in the Heat templates. A tox genconfig target
is added that mirrors how the other OpenStack services generate
their sample config files.
A description of the available options for the input file is
provided in a README file in the sample-env-generator directory.
In this commit only a single sample config is provided as a basic
example of how the tool works, but subsequent commits will add
more generated sample configs.
Change-Id: I855f33a61bba5337d844555a7c41b633b3327f7a
bp: environment-generator
This patch updates the pep8 task (which is executed in CI) so
that it generates templates locally. This will give us extra
CI coverage to ensure our generated templates produce valid
YAML.
Change-Id: I2287802d44c0ebe404d3fce30f04efcc3c6ab27f
This patch adds a local version of our template processing
routine so that developers can more quickly view the templates
that are actually getting generated. I've noticed multiple developers
now do a full deployment with 'overcloud deploy' only to download
the swift container with the generated templates. This simple task
avoids that step by allowing developers to generate it locally.
It also aims to preserve the ability to use t-h-t templates directly
with Heat (instead of going through Mistral) should users wish to do that.
The new undercloud heat installer requires the ability to generate
templates without requiring Mistral and Swift to do so.
Ideally the Mistral API workflow would use this same code
so perhaps in the future we might modify that routine to:
-download swift tarball containing the templates
-run this local routine that lives in t-h-t
-re-upload the tarball of templates to the swift container
Change-Id: Ie664c9c5f455b7320a58a26f35bc403355408d9b
This is the new blessed naming scheme for lint-type jobs such as
pep8 or the yaml validation job we have in this project. Doing
this rename will allow us to use standard infra job templates
to run validation on proposed changes.
Change-Id: I0a4c4372429a08e0babb4d323f2b027f1d95f3d7
Adds a "validate" tox env for basic sanity checking of templates.
Currently it just validates that all of the .yaml files are in fact
valid YAML. In the future we might want to add more, but this
seemed like a reasonable start.
Change-Id: I8091bbad0003b150e23dae5de4f465053c982229