expaned guidelines

Signed-off-by: Larry Peterson <[email protected]>

Author: llpeterson

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).
+