From 437a88e4516d8c99211cbce535a25532bd3c5493 Mon Sep 17 00:00:00 2001 From: Thomas Wiest Date: Tue, 26 May 2015 10:15:31 -0400 Subject: Added concepts guide. --- docs/best_practices.adoc | 122 ----------------------------------------- docs/best_practices_guide.adoc | 122 +++++++++++++++++++++++++++++++++++++++++ docs/core_concepts_guide.adoc | 42 ++++++++++++++ docs/style_guide.adoc | 2 +- 4 files changed, 165 insertions(+), 123 deletions(-) delete mode 100644 docs/best_practices.adoc create mode 100644 docs/best_practices_guide.adoc create mode 100644 docs/core_concepts_guide.adoc (limited to 'docs') diff --git a/docs/best_practices.adoc b/docs/best_practices.adoc deleted file mode 100644 index 938b6b46a..000000000 --- a/docs/best_practices.adoc +++ /dev/null @@ -1,122 +0,0 @@ -// vim: ft=asciidoc - -= Openshift-Ansible Best Practices Guide - -The purpose of this guide is to describe the preferred patterns and best practices used in this repository (both in ansible and python). - -It is important to note that this repository may not currently comply with all best practices, but our intention is that it will. - -All new pull requests created against this repository MUST comply with this guide. - -This guide complies with https://www.ietf.org/rfc/rfc2119.txt[RFC2119]. - - -== Pull Requests - -[cols="2v,v"] -|=== -| **Rule** -| All pull requests MUST pass the build bot *before* they are merged. -|=== - - -The purpose of this rule is to avoid cases where the build bot will fail pull requests for code modified in a previous pull request. - -Our tooling is flexible enough that exceptions can be made so that the tool the build bot is running will ignore certain areas or certain checks, but the build bot itself must pass for the pull request to be merged. - - - -== Python - -=== PyLint -We use http://www.pylint.org/[PyLint] in an attempt to keep our python code as clean and as managable as possible. Our build bot runs each pull request through PyLint and any warnings or errors cause the build bot to fail the pull request. - -''' -[cols="2v,v"] -|=== -| **Rule** -| PyLint rules MUST NOT be disabled on a whole file. -|=== - -Instead, http://docs.pylint.org/faq.html#is-it-possible-to-locally-disable-a-particular-message[disable the PyLint check on the line where PyLint is complaining]. - -''' -[cols="2v,v"] -|=== -| **Rule** -| PyLint rules MUST NOT be disabled unless they meet one of the following exceptions -|=== - -.Exceptions: -1. When PyLint fails because of a dependency that can't be installed on the build bot -1. When PyLint fails because we are including a module that is outside of our control (like Ansible) - -''' -[cols="2v,v"] -|=== -| **Rule** -| All PyLint rule disables MUST be documented in the code. -|=== - -The purpose of this rule is to inform future developers about the disable. - -.Specifically, the following MUST accompany every PyLint disable: -1. Why is the check being disabled? -1. Is disabling this check meant to be permanent or temporary? - -.Example: -[source,python] ----- -# Reason: disable pylint maybe-no-member because overloaded use of -# the module name causes pylint to not detect that 'results' -# is an array or hash -# Status: permanently disabled unless we can find a way to fix this. -# pylint: disable=maybe-no-member -metadata[line] = results.pop() ----- - - -== Ansible - -=== Filters -.Context: -* https://docs.ansible.com/playbooks_filters.html[Ansible Playbook Filters] -* http://jinja.pocoo.org/docs/dev/templates/#builtin-filters[Jinja2 Builtin Filters] - -''' -[cols="2v,v"] -|=== -| **Rule** -| The `default` filter SHOULD replace empty strings, lists, etc. -|=== - -When using the jinja2 `default` filter, unless the variable is a boolean, specify `true` as the second parameter. This will cause the default filter to replace empty strings, lists, etc with the provided default. - -This is because we would prefer to either have a sane default set than to have an empty string, list, etc. We don't, for example, want config values set to an empty string. - -.From the http://jinja.pocoo.org/docs/dev/templates/[Jinja2 Docs]: -[quote] -If you want to use default with variables that evaluate to false you have to set the second parameter to true - -.Example: -[source,yaml] ----- ---- -- hosts: localhost - gather_facts: no - vars: - somevar: '' - tasks: - - debug: var=somevar - - - name: "Will output 'somevar: []'" - debug: "msg='somevar: [{{ somevar | default('the string was empty') }}]'" - - - name: "Will output 'somevar: [the string was empty]'" - debug: "msg='somevar: [{{ somevar | default('the string was empty', true) }}]'" ----- - - -In other words, normally the `default` filter will only replace the value if it's undefined. By setting the second parameter to `true`, it will also replace the value if it defaults to a false value in python, so None, empty list, empty string, etc. - -We almost always want this instead of the empty list, string, etc. diff --git a/docs/best_practices_guide.adoc b/docs/best_practices_guide.adoc new file mode 100644 index 000000000..938b6b46a --- /dev/null +++ b/docs/best_practices_guide.adoc @@ -0,0 +1,122 @@ +// vim: ft=asciidoc + += Openshift-Ansible Best Practices Guide + +The purpose of this guide is to describe the preferred patterns and best practices used in this repository (both in ansible and python). + +It is important to note that this repository may not currently comply with all best practices, but our intention is that it will. + +All new pull requests created against this repository MUST comply with this guide. + +This guide complies with https://www.ietf.org/rfc/rfc2119.txt[RFC2119]. + + +== Pull Requests + +[cols="2v,v"] +|=== +| **Rule** +| All pull requests MUST pass the build bot *before* they are merged. +|=== + + +The purpose of this rule is to avoid cases where the build bot will fail pull requests for code modified in a previous pull request. + +Our tooling is flexible enough that exceptions can be made so that the tool the build bot is running will ignore certain areas or certain checks, but the build bot itself must pass for the pull request to be merged. + + + +== Python + +=== PyLint +We use http://www.pylint.org/[PyLint] in an attempt to keep our python code as clean and as managable as possible. Our build bot runs each pull request through PyLint and any warnings or errors cause the build bot to fail the pull request. + +''' +[cols="2v,v"] +|=== +| **Rule** +| PyLint rules MUST NOT be disabled on a whole file. +|=== + +Instead, http://docs.pylint.org/faq.html#is-it-possible-to-locally-disable-a-particular-message[disable the PyLint check on the line where PyLint is complaining]. + +''' +[cols="2v,v"] +|=== +| **Rule** +| PyLint rules MUST NOT be disabled unless they meet one of the following exceptions +|=== + +.Exceptions: +1. When PyLint fails because of a dependency that can't be installed on the build bot +1. When PyLint fails because we are including a module that is outside of our control (like Ansible) + +''' +[cols="2v,v"] +|=== +| **Rule** +| All PyLint rule disables MUST be documented in the code. +|=== + +The purpose of this rule is to inform future developers about the disable. + +.Specifically, the following MUST accompany every PyLint disable: +1. Why is the check being disabled? +1. Is disabling this check meant to be permanent or temporary? + +.Example: +[source,python] +---- +# Reason: disable pylint maybe-no-member because overloaded use of +# the module name causes pylint to not detect that 'results' +# is an array or hash +# Status: permanently disabled unless we can find a way to fix this. +# pylint: disable=maybe-no-member +metadata[line] = results.pop() +---- + + +== Ansible + +=== Filters +.Context: +* https://docs.ansible.com/playbooks_filters.html[Ansible Playbook Filters] +* http://jinja.pocoo.org/docs/dev/templates/#builtin-filters[Jinja2 Builtin Filters] + +''' +[cols="2v,v"] +|=== +| **Rule** +| The `default` filter SHOULD replace empty strings, lists, etc. +|=== + +When using the jinja2 `default` filter, unless the variable is a boolean, specify `true` as the second parameter. This will cause the default filter to replace empty strings, lists, etc with the provided default. + +This is because we would prefer to either have a sane default set than to have an empty string, list, etc. We don't, for example, want config values set to an empty string. + +.From the http://jinja.pocoo.org/docs/dev/templates/[Jinja2 Docs]: +[quote] +If you want to use default with variables that evaluate to false you have to set the second parameter to true + +.Example: +[source,yaml] +---- +--- +- hosts: localhost + gather_facts: no + vars: + somevar: '' + tasks: + - debug: var=somevar + + - name: "Will output 'somevar: []'" + debug: "msg='somevar: [{{ somevar | default('the string was empty') }}]'" + + - name: "Will output 'somevar: [the string was empty]'" + debug: "msg='somevar: [{{ somevar | default('the string was empty', true) }}]'" +---- + + +In other words, normally the `default` filter will only replace the value if it's undefined. By setting the second parameter to `true`, it will also replace the value if it defaults to a false value in python, so None, empty list, empty string, etc. + +We almost always want this instead of the empty list, string, etc. diff --git a/docs/core_concepts_guide.adoc b/docs/core_concepts_guide.adoc new file mode 100644 index 000000000..0d746bfb5 --- /dev/null +++ b/docs/core_concepts_guide.adoc @@ -0,0 +1,42 @@ +// vim: ft=asciidoc + += Openshift-Ansible Core Concepts Guide + +The purpose of this guide is to describe core concepts used in this repository. + +It is important to note that this repository may not currently implement all of the concepts, but our intention is that it will. + +== Logical Grouping Concepts +The following are the concepts we use to logically group OpenShift cluster instances. + +We use these groupings to perform operations specifically against instances in the specified group. + +For example, run an Ansible playbook against all instances in the `production` environment, or run an adhoc command against all instances in the `acme-corp` cluster group. + +=== Cluster +A Cluster is a complete install of OpenShift (master, nodes, registry, router, etc). + +Example: Acme Corp has sales and marketing departments that both want to use OpenShift for their internal applications, but they do not want to share resources because they have different cost centers. Each department could have their own completely separate install of OpenShift. Each install is a separate OpenShift cluster. + +Defined Clusters: +`acme-sales` +`acme-marketing` + +=== Cluster Group +A cluster group is a logical grouping of one or more clusters. Which clusters are in which cluster groups is determined by the OpenShift administrators. + +Example: Extending the example above, both marketing and sales clusters are part of Acme Corp. Let's say that Acme Corp contracts with Hosting Corp to host their OpenShift clusters. Hosting Corp could create an Acme Corp cluster group. + +This would logically group Acme Corp resources from other Hosting Corp customers, which would enable the Hosting Corp's OpenShift administrators to run operations specifically targeting Acme Corp instances. + +Defined Cluster Group: +`acme-corp` + +=== Environment +An environment is a logical grouping of one or more cluster groups. How the environment is defined is determined by the OpenShift administrators. + +Example: Extending the two examples above, Hosting Corp could provide both production and staging environments for it's customers. In this way, Acme Corp could push their code to the staging environment and test it out before pushing it to production. + +Defined Environments: +`production` +`staging` diff --git a/docs/style_guide.adoc b/docs/style_guide.adoc index 26a8c4636..714b56c70 100644 --- a/docs/style_guide.adoc +++ b/docs/style_guide.adoc @@ -1,7 +1,7 @@ // vim: ft=asciidoc = Openshift-Ansible Style Guide ------------------------------ + The purpose of this guide is to describe the preferred coding conventions used in this repository (both in ansible and python). It is important to note that this repository may not currently comply with all style guide rules, but our intention is that it will. -- cgit v1.2.3