From ab1898abee95246cbb689e6d30565e0e8b7ade7b Mon Sep 17 00:00:00 2001 From: Larry Peterson Date: Wed, 4 Sep 2024 09:18:56 -0700 Subject: [PATCH] expaned guidelines Signed-off-by: Larry Peterson --- onramp/blueprints.rst | 18 ++++++++++++++---- 1 file changed, 14 insertions(+), 4 deletions(-) diff --git a/onramp/blueprints.rst b/onramp/blueprints.rst index 23bc484..57ef996 100644 --- a/onramp/blueprints.rst +++ b/onramp/blueprints.rst @@ -672,15 +672,25 @@ recommend the following guidelines. * Keep blueprints fairly narrow. One of their main values is to document (in code) how a particular feature is enabled and configured. Introduce new roles to keep playbooks narrow. Introduce - new values files to keep each example override file narrow. + new values override files (and other config files) to keep each + example narrow. * Use Ansible best-practices for defining playbooks. This means using Ansible plugins rather than invoking shell scripts, whenever possible. -* Minimize the number of variables exposed in +* Avoid exposing too many variables in ``vars/main-blueprint.yml``. Their main purpose is direct how Ansible deploys Aether, and not to configure the individual subsystems of a given deployment. The latter details are best - defined in a values override file, which can then be referenced by - ``vars/main-blueprint.yml``. + defined in component-specific configuration files (e.g., values + override files), which can then be referenced by + ``vars/main-blueprint.yml``. The main exception is variables + that enable/disable a particular feature. Two good examples are + ``core.standalone`` and ``oai.simulation``. + +* Avoid embedding configuration parameters in Ansible playbooks. + Such parameters should be collected in either ``vars/main-blueprint.yml`` + or a component-specific configuration file, depending on their + purpose (see previous item). +