RC2 draft 🎈 (#22)

PR for the second release candidate, incorporating feedback from RC 1 by GitOps Working Group and
community participants. After merge, we will create an RC 2 release branch and tag the release. RC 2 is the last planned release candidate before the [v1.0.0 milestone](https://github.com/open-gitops/documents/milestone/1), scheduled to release before Kubecon NA, 2021.

Any open discussions from feedback will be moved to issues and attached to the appropriate milestone. These may be addressed either the v1.0.0 milestone or after depending on how motivated its proponents are, and how consensus from the GitOps Working Group unfolds.

## About OpenGitOps

OpenGitOps is a CNCF Sandbox project for lasting programs, documents and code from the [GitOps Working Group](https://github.com/gitops-working-group/gitops-working-group/).

## About the GitOps Working Group

The GitOps Working Group is an open group, inviting companies and individuals to join and contribute to the community and the adoption of GitOps across the cloud native landscape. There are many ways to [get involved](https://github.com/gitops-working-group/gitops-working-group/blob/main/README.md#how-to-get-involved). Here are a few:

## Getting Involved

- [Star](https://docs.github.com/en/github/getting-started-with-github/exploring-projects-on-github/saving-repositories-with-stars) and [watch](https://docs.github.com/en/github/managing-subscriptions-and-notifications-on-github/setting-up-notifications/configuring-notifications) the [OpenGitOps Documents](https://github.com/open-gitops/documents) and [GitOps Working Group](https://github.com/gitops-working-group/gitops-working-group) repos to see when things change
- For more, see https://github.com/open-gitops/.github/blob/main/CONTRIBUTING.md

## Changelog

## Attribution

RC 2 drafted by:
Co-authored-by: Dan Garfield <dan@todaywasawesome.com>
Co-authored-by: Scott Rigby <scott@r6by.com>

With feedback from meeting participants:
Co-authored-by: Christian Hernandez <christian@redhat.com>
Co-authored-by: Moshe Immerman <moshe@flanksource.com>
Co-authored-by: Chris Short <chris@chrisshort.net>
And John Hession (can not find co-authorship email)

And PR in collaboration with:
Co-authored-by: Michael Bridgen <mikeb@squaremobius.net>
Co-authored-by: Lloyd Chang <lloydchang@gmail.com>
Co-authored-by: Brian Fox <brian@midnite-it.se>
Co-authored-by: Moshe Immerman <moshe@flanksource.com>
Co-authored-by: Cansu Kavılı Örnek <ckavili@redhat.com>
Co-authored-by: Piotr <decoder@live.de>
Co-authored-by: Chris Sanders <csand@microsoft.com>

## Review changes on this PR were:

* Remove breaking glass language as it is no longer referenced. This is something we may add back later as we add things.

Signed-off-by: Dan Garfield <dan@todaywasawesome.com>

* Revise wording to make each definition more clear. Also remove the extra components under software system.

Signed-off-by: Dan Garfield <dan@todaywasawesome.com>

* Fixed 3 typos

3 small typos were fixed in the document.

Co-authored-by: Lloyd Chang <lloydchang@gmail.com>
Co-authored-by: Cansu Kavılı Örnek <ckavili@redhat.com>

Signed-off-by: Piotr <decoder@live.de>

* Remove CIOps and use standard language to clarify reconciliation.

Signed-off-by: Dan Garfield <dan@todaywasawesome.com>

* Add space

Co-authored-by: Brian Fox <brianhfox@gmail.com>

Signed-off-by: Dan Garfield <dan@todaywasawesome.com>

* Remove unnecessary 'declarations' modifier

Co-authored-by: Brian Fox <brian@midnite-it.se>

Signed-off-by: Scott Rigby <scott@r6by.com>

* Update Desired State glossary item

Co-authored-by: Lloyd Chang <lloydchang@gmail.com>
Co-authored-by: Michael Bridgen <mikeb@squaremobius.net>
Co-authored-by: Dan Garfield <dan@todaywasawesome.com>

Signed-off-by: Scott Rigby <scott@r6by.com>

* Clarify "drift" means moving away from desired state not moving toward

Good note Michael, important to be precise here.

Co-authored-by: Michael Bridgen <mikeb@squaremobius.net>
Co-authored-by: Dan Garfield <dan@todaywasawesome.com>
Co-authored-by: Lloyd Chang <lloydchang@gmail.com>

Signed-off-by: Scott Rigby <scott@r6by.com>

Co-authored-by: Piotr <decoder@live.de>
Co-authored-by: Scott Rigby <scott@r6by.com>

Signed-off-by: Scott Rigby <scott@r6by.com>

GLOSSARY.md

@@ -2,48 +2,39 @@
 
 This glossary accompanies the [GitOps Principles](./PRINCIPLES.md), and other supporting documents in this repository.
 
-- ## Break Glass
-
-    The temporary suspension of GitOps principles, often accomplished by pausing automated [reconciliation](#reconciliation).
-    While these principles apply to typical operations, it may at times be necessary to temporarily pause reconciliation, for example during incident management activities.
-    In these cases, other modes of operations should be considered (e.g. manual intervention), followed by any necessary updates to the desired state declarations, and finally resuming reconciliation of the system with the updated declarations.
-    Pragmatic exceptions to these guiding principles are expected from time to time during the journey toward a system being fully managed by GitOps.
-
 - ## Continuous
 
-    By "continuous" we adopt the industry standard to mean that [reconciliation](#reconciliation) continues to happen, not that it must be instantaneous.
+    "Continuous" is intended to match the industry standard term: [reconciliation](#reconciliation) continues to happen, not that it must be instantaneous.
 
 - ## Declarative Description
 
-    Describing the desired state or behavior of a system without specifying how that state will be achieved, thereby separating configuration (the desired state) from the implementation (commands, API calls, scripts etc.) that actually achieves the desired state described in the declarative description.
+    A configuration that describes the desired operating state of a system without specifying procedures for how that state will be achieved. This separates configuration (the desired state) from the implementation (commands, API calls, scripts etc.) used to achieve that state.
 
 - ## Desired State
 
-    The aggregate of all configuration data for a system form its desired state which is defined as data sufficient to recreate the system so that instances of the system are behaviourally indistinguishable, but do not include the state of any data stored within the system, eg. database contents.
+    The aggregate of all configuration data for a system form its desired state which is defined as data sufficient to recreate the system so that instances of the system are behaviourally indistinguishable.
+    This configuration data generally does not include persistent application data, eg. database contents, though often does include credentials for accessing that data, or configuration for data recovery tools running on that system.
 
 - ## Drift
 
-    When a system's actual state changes for any reason other than its versioned [desired state](#desired-state) declarations having changed, we say that the system has drifted from its desired state.
+    When a system's actual state has moved or is in the process of moving away from the [desired state](#desired-state), this is often referred to as drift.
 
 - ## Reconciliation
 
-    The process of ensuring that the actual state of a system matches its [desired state](#desired-state) declarations.
-    Contrary to CIops, any divergence between the two will trigger reconciliation, regardless of where changes occured.
-    Divergence could be due to the actual state unintentionally [drifting](#drift) from the desired state declarations, or a new desired state declaration version having been changed intentionally.
+    The process of ensuring the actual state of a system matches its [desired state](#desired-state).
+    Contrary to traditional CI/CD where automation is generally driven by pre-set triggers, in GitOps reconciliation is triggered whenever there is a divergence. Divergence could be due to the actual state unintentionally [drifting](#drift) from the desired state declarations, or a new desired state declaration version having been changed intentionally.
 
 - ## Software System
 
-  We currently understand a software system to include:
+    A software system managed by GitOps includes:
 
-  - One or more runtime environments consisting of resources under management
-  - In each runtime, the management agents which act on resources according to security policies
-  - One or more software repositories for storing deployable artifacts that may be loaded into the runtime environments, eg. configuration files, code, binaries, and packages
-  - One or more Administrators who are responsible for operating the runtime environments ie. installing, starting, stopping and updating software, code, configuration, etc
-  - A set of policies controlling access and management of repositories, deployments, runtimes
+    1. One or more runtime environments consisting of resources under management
+    1. The management agents within each runtime
+    1. Policies for controlling access and management of repositories, deployments, runtimes
 
 - ## State Store
 
     A system for storing immutable versions of [desired state](#desired-state) declarations.
     This state store should provide access control and auditing on the changes to the Desired State.
     Git, from which GitOps derives its name, is the canonical example used as this state store but any other system that meets these criteria may be used.
-    In all cases, these state stores must be properly configured and special precautions must be taken to comply with requirements set out in the GitOps Principles.
+    In all cases, these state stores must be properly configured and precautions must be taken to comply with requirements set out in the GitOps Principles.