| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
This replicates the behavior of the custom Jinja2 loader from tripleo-common to
allow template validation on the local filesystem using tox.
Change-Id: I27683ab31187c6334dc5b4b5363a3347874b9a90
Partially-Implements: blueprint overcloud-upgrades-per-service
Depends-On: Idc5c3f49c7a2fc7f3622c76da001992cc657384e
|
|
Allow for passing the output_dir in the process-templates scripts so
that it doesn't overwrites the templates in the src dir. This is a
desired feature when running the script from a t-h-t installed
system-wide.
Change-Id: I47994d34f47a4084a11124bc9075cb2f457889ea
|
|
Don't walk through hidden files. This avoids going through the .git,
.tox and other hidden directories that we don't care about.
Change-Id: I34b83229775d221299c8b572a7049175debac99d
|
|
The error path for this fails because we don't import six
or install it in the templates tox venv
Change-Id: Ie9f46332f2b03d48a1b0a4a432e9721757833569
|
|
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
|
Oliver Walsh
Flavio Percoco
Steven Hardy
Dan Prince