|Age||Commit message (Collapse)||Author||Files||Lines|
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
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.
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.
Use the openstack upper-constraints when running tox.
Add ReNo support to manage release notes.
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
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
It turns out the linters rename was a bit premature. Use the
current standard pep8 name so we don't need custom jobs in the
gate to run this test on proposed changes.
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.
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.
We can now release through openstack.org infrastructure.