host-config-and-reboot interface was deprecated in Queens in favor of:
OS::TripleO::Services::BootParams: extraconfig/pre_network/boot-params-service.yaml
and doesn't work with config-download, which has been the default since
Rocky.
Let's remove these files.
Change-Id: I85a781cecb7224881b827ff442376c706f1c771b
Ignore disabled networks when rendering templates.
Add's the ctlplane network to maps to ensure we don't
end up with no keys/values in map_replace functions.
Also some Jinja cleanup:
- Reduce the number of times we iterate over networks
where we can.
- Add's indentation to make the code easier to read.
Related-Bug: #1809313
Depends-On: I2e8135bc9389d3bf1a6ef01e273515af5c488a9a
Change-Id: Ifeb2d2d1acb43c16a5bf29e95965776494d61fef
It is possible to use the process_templates script to generate the
user's jinja templates based on role and network data. But the script
expects the presence of j2_excludes file. Making it as optional, allows
users to generate templates in user's template directory itself, like
$ /usr/share/openstack-tripleo-heat-templates/tools/process-templates.py \
-p ~/templates/ \
-r ~/templates/roles_data.yaml \
-n ~/templates/network_data.yaml
Closes-Bug: #1806351
Change-Id: I375cd9ff9b40bbdad34d0732ec8abd25fbdde46e
When running the process-templates script with both the -o OUTPUT_DIR and
-p BASE_PATH options the output files were not being written to the output
directory. This fix splits out the file path from the base path to properly
write the files.
Change-Id: I845e8a2cbd2b12a4a1552b2cfa3ac013466da6bd
Closes-Bug: #1794769
Don't assume the role dict has a deprecated_nic_config_name key during
cleanup of the process templates. This isn't a required field, so we
can't assume it exists, otherwise the script will traceback with a
KeyError.
Change-Id: I50eb4831c2b413e2253cb0c3dc9aba4c719f0f14
Sometimes it is nice to know which templates
should be rendered into which files. For example,
if we need to define additional checks in the client.
Change-Id: I10d4dffcd3802f62fc824c808728c0b5b4f1002c
Signed-off-by: Bogdan Dobrelya <bdobreli@redhat.com>
Also delete the newly rendered per-role sample nic config templates when
process-templates.py is called with --clean.
Change-Id: Ic77b3c9e243839201065260b5807d145c4bb9972
This change converts the existing NIC templates to jinja2 in
order to dynamically render the ports and networks according
to the network_data.yaml. If networks are added to the
network_data.yaml file, parameters will be added to all
NIC templates. The YAML files (as output from jinja with
the default network_data.yaml) are present as an example.
The roles in roles_data.yaml are used to produce NIC configs
for the standard and custom composable roles. In order to
keep the ordering of NICs the same in the multiple-nics
templates, the order of networks was changed in the
network_data.yaml file. This is reflected in the network
templates, and in some of the files that is the only
change.
The roles and roles_data.yaml were modified to include
a legacy name for the NIC config templates for the
built-in roles Controller, Compute, Object Storage,
Block Storage, Ceph Storage, Compute-DPDK, and
Networker roles. There will now be a file produced
with the legacy name, but also one produced with the
<role>-role.j2.yaml format (along with environment
files to help use the new filenames).
Note this change also fixes some typos as well as
a number of templates that had VLANs with device:
entries which were ignored.
Closes-Bug: 1737041
Depends-On: I49c0245c36de3103671080fd1c8cfb3432856f35
Change-Id: I3bdb7d00dab5a023dd8b9c94c0f89f84357ae7a4
When copying templates or files with the
process-templates.py's shutil, ignore cases when
the source and the destination are same files.
This allows the following scenario:
- Symlink t-h-t from the installed package to a work dir
- Process j2 templates with overwrite in the work dir
Required-by: https://review.openstack.org/#/c/542875
Change-Id: I9a9c32f05fde325709998f4fe8bc7fef6c25b5c5
Signed-off-by: Bogdan Dobrelya <bdobreli@redhat.com>
Templates processor fails to locate *.j2 files,
when a custom output dir is specified.
Ensure *.j2 templates are on their expected search
paths for upcoming pasring and rendering
Change-Id: Idbc93e27574c66a9a5a73e3fcd7e88647282f201
Closes-bug: #1748425
Signed-off-by: Bogdan Dobrelya <bdobreli@redhat.com>
Add a new option to process-templates.py that will clean the working
template directory of any generated template files.
Change-Id: I7283d25260c1501964c240c89dd4f658d5c14a3b
This change adds templates that are used to create network and
port definition templates for each network that is defined in
network_data.yaml. In order to render the templates, additional
fields have been added to the network_data.yaml file. If this
optional data is present, it will be used to populate the default
parameter values in the network template.
The only required parameters in the network_data.yaml file is
the network name. If the network will have IPv6 addresses, then
ipv6: true must be set on the network.
The existing networks have been modeled in the network_data.yaml,
but until these templates are removed from the j2_excludes.yaml
file they will not be generated on the fly. Any additional
networks will have templates generated.
This change also removes an unnecessary conditional from the
networks.j2.yaml file, since InternalApiNetwork doesn't need
to be reformatted as InternalNetwork (it's only used in this
one file).
A follow-up patch will remove the existing network definitions
so all networks are created dynamically.
Change-Id: If074f87494a46305c990a0ea332c7b576d3c6ed8
Depends-On: Iab8aca2f1fcaba0c8f109717a4b3068f629c9aab
Partially-Implements: blueprint composable-networks
Render all per-network resources and interfaces via j2 to enable
future support for custom networks via network_data.yaml
Note this doesn't enable custom networks for the built-in roles
as we skip j2 rendering for them, this will be resolved by converting
them to use the generic role template instead of the hard-coded
ones listed in the j2_excludes.yaml.
Depends-On: I18fa3829ff38ac200550d8e36bbe334c0005da22
Change-Id: I49565f9389f3ec9aef4861e23a3bed64a85501e6
Partially-Implements: blueprint composable-networks
Currently we only consume the name with a special-case
for the disable constraints boolean, but it will be more
flexible if we consume the whole roles_data mapping for
each role, so that e.g composable networks and other
per-role customizations can be expressed in these
templates
Partially-Implements: blueprint composable-networks
Depends-On: Id1249b78b3dd87e91d572ffa31b7a541f3cde2c7
Change-Id: I355534ec456479944f66106e957404a660d8f2d2
This moves the hard-coded networks from the default environment,
and provides the first step towards enabling composable networks.
Co-Author: Dan Sneddon <dsneddon@redhat.com>
Partial-Bug: #1633090
Depends-On: I9f818912bd8e2a3220e41c8ccbbab3d9063b4d72
Change-Id: I7793b8badede5450b05437c84d9b40c28de7546b
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
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