Age | Commit message (Collapse) | Author | Files | Lines |
|
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
|
|
Use the openstack upper-constraints when running tox.
Change-Id: I9eef36eec749beec0effdb2309fe2ceb9bc557f8
Related-Bug: #1691511
|
|
Change-Id: I72aa48c72c825151739cb478c58e9a6c841c9130
|
|
Add ReNo support to manage release notes.
http://docs.openstack.org/developer/reno/
Change-Id: Ie5154d909e616e4e7e813052f9c121d6ac5b0875
|
|
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
|
|
It turns out the linters rename was a bit premature[1]. Use the
current standard pep8 name so we don't need custom jobs in the
gate to run this test on proposed changes.
Change-Id: I5226d4c5e3d4095d76cba24fcf27f87c59730587
1: http://lists.openstack.org/pipermail/openstack-dev/2016-February/086268.html
|
|
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
|
|
We can now release through openstack.org infrastructure.
Change-Id: I6dff6ae4a97db15bdc4ce419e46e9a125bec277c
|