summaryrefslogtreecommitdiffstats
path: root/docs/proposals/role_decomposition.md
diff options
context:
space:
mode:
authorewolinetz <ewolinet@redhat.com>2017-04-27 16:48:11 -0500
committerewolinetz <ewolinet@redhat.com>2017-04-27 16:48:11 -0500
commitbb9d1bd8af41c79586eb1c5d7b4f75932b632442 (patch)
tree47dfb5b9c888c69ff577b0a9cec321a6e6bf4d69 /docs/proposals/role_decomposition.md
parent66f18efad7176eb4f1ad1926a9a3b5d96aa72e2f (diff)
downloadopenshift-bb9d1bd8af41c79586eb1c5d7b4f75932b632442.tar.gz
openshift-bb9d1bd8af41c79586eb1c5d7b4f75932b632442.tar.bz2
openshift-bb9d1bd8af41c79586eb1c5d7b4f75932b632442.tar.xz
openshift-bb9d1bd8af41c79586eb1c5d7b4f75932b632442.zip
Adding some more sections to additional considerations, being less rigid on large roles for composing -- can also be a playbook
Diffstat (limited to 'docs/proposals/role_decomposition.md')
-rw-r--r--docs/proposals/role_decomposition.md42
1 files changed, 40 insertions, 2 deletions
diff --git a/docs/proposals/role_decomposition.md b/docs/proposals/role_decomposition.md
index 228b7de12..b6c1d8c5b 100644
--- a/docs/proposals/role_decomposition.md
+++ b/docs/proposals/role_decomposition.md
@@ -27,7 +27,8 @@ A role should be considered for decomposition if it:
side by side.
1) Has different entry points for upgrading and installing a product
-Large roles should be responsible for:
+Large roles<sup>1</sup> should be responsible for:
+> 1 or composing playbooks
1) Composing smaller roles to provide a full solution such as an Openshift Master
1) Ensuring that smaller roles are called in the correct order if necessary
@@ -312,4 +313,41 @@ roles should be able to fall within these guidelines.
# Additional considerations
-Playbooks including playbooks (link to rteague's presentation?)
+## Playbooks including playbooks
+In some circumstances it does not make sense to have a composing role but instead
+a playbook would be best for orchestrating the role flow. Decisions made regarding
+playbooks including playbooks will need to be taken into consideration as part of
+defining this process.
+Ref: (link to rteague's presentation?)
+
+## Role dependencies
+We want to make sure that our roles do not have any extra or unnecessary dependencies
+in meta/main.yml without:
+
+1. Proposing the inclusion in a team meeting or as part of the PR review and getting agreement
+1. Documenting in meta/main.yml why it is there and when it was agreed to (date)
+
+## Avoiding overly verbose roles
+When we are splitting our roles up into smaller components we want to ensure we
+avoid creating roles that are, for a lack of a better term, overly verbose. What
+do we mean by that? If we have `openshift_master` as an example, and we were to
+split it up, we would have a component for `etcd`, `docker`, and possibly for
+its rpms/configs. We would want to avoid creating a role that would just create
+certificates as those would make sense to be contained with the rpms and configs.
+Likewise, when it comes to being able to restart the master, we wouldn't have a
+role where that was its sole purpose.
+
+The same would apply for the `etcd` and `docker` roles. Anything that is required
+as part of installing `etcd` such as generating certificates, installing rpms,
+and upgrading data between versions should all be contained within the single
+`etcd` role.
+
+## Enforcing standards
+Certain naming standards like variable names could be verified as part of a Travis
+test. If we were going to also enforce that a role either has tasks or includes
+(for example) then we could create tests for that as well.
+
+## CI tests for individual roles
+If we are able to correctly split up roles, it should be possible to test role
+installations/upgrades like unit tests (assuming they would be able to be installed
+independently of other components).