We have environments that are exclusively resource_registry entries,
and we shouldn't have to include a dummy files: key to make that
work with the generator.
Change-Id: I8ffabb5e583aabbfa4f2f22a4418783c857118fa
Certs were being generated for all networks in service net map.
This was failing as we do not generate hieradata for all of these networks.
Switching from yaql to jinga templating to match the logic that
generates the hieradata.
Change-Id: Ic6c25aceb07ea3824a8fb23549bc5d1205e5cefc
Closes-bug: 1748023
Closes-Bug: 1748053
We use yaql in many hot templates, but they are usually faily obscure
and not documented, which makes it hard to change them over time (to
make them perform better for example).
This introduces some basic infrastructure for testing them, as well as a
first modification to show how things would be easier to change.
Change-Id: I1a8d3a514d8fa0de4b024d3ae320723d791f3e7d
It is possible to pass parameters only to a specific role by using an
environment with a <role name>Parameters dict. This change adds support
for sample environments with such nested parameters.
Change-Id: I7eb91d4262013341fab733342ab313caf8cec118
This patch fix the following error when running python3
TypeError: can only concatenate list (not "dict_keys") to list
Change-Id: Ic487bf4c4f6cb2bc35011416056bef1417a23076
The method "generate_environments" in environment_generator.py
takes two arguments but 1 given in "test_environment_generator.py"
Change-Id: I39abcf2340ce04f3d193d80c8af177027c512556
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
All of the other SSL environments were converted, but this one was
missed. That's an inconsistent user experience and should be
cleaned up.
This environment also exposed a bug in the tool where it did not
include the parameter_defaults section key if all the parameters
were marked static.
Change-Id: I19bc422c22b9f60f781e696ce703b026dc317786
Closes-Bug: 1713761
It looks like this was added recently and it doesn't appear to be a
parameter we want in the sample environments.
Change-Id: I0ac433553e7ad9b0a54c011b66c54b4692b44be0
Fix a bug that prevented these working. A unit test and
documentation for the nested environment functionality is also
included.
Change-Id: I2d4aeb584eb624178d601cfd6bc0a6473cb5289f
Starts converting storage-related sample environments to the tool,
and adds a few new ones for demonstration purposes.
This has required the addition of a new category of parameter
overrides in the tool. There are some parameters that are part of
the public API of roles that should not normally be included in a
sample environment for that role. Examples are EndpointMap and
ServiceNetMap. Those are both passed into most (all?) roles, but
their template defaults are not useful (both default to {}).
Unless we are explicitly creating a sample environment that
overrides those defaults we don't want them included.
Parameters such as RoleName and RoleParameters are similar. We
can't change them because they are part of the composable roles
interface and that would break any existing custom roles, but we
don't really want them included normally either. It's possible
these could be made completely private, but there have been some
very preliminary discussions about generating role samples that
might actually want to set them.
In order to avoid issues with editing the unit test file in editors
that strip trailing whitespace, the minor formatting bug where
params like EndpointMap had a trailing space after the name has
also been fixed.
Change-Id: If11f30c734bfbc17d463a9890c736d7477186fb9
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