Skip to content

Commit

Permalink
Merge pull request #22 from opennetworkinglab/maintenance
Browse files Browse the repository at this point in the history
expaned guidelines
  • Loading branch information
llpeterson authored Sep 4, 2024
2 parents 625467d + ab1898a commit 73451de
Showing 1 changed file with 14 additions and 4 deletions.
18 changes: 14 additions & 4 deletions onramp/blueprints.rst
Original file line number Diff line number Diff line change
Expand Up @@ -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).

0 comments on commit 73451de

Please sign in to comment.