-
Notifications
You must be signed in to change notification settings - Fork 60
Move control-loop rom principle to glossary for now #31
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from all commits
af283d9
494a5a9
f3dea2c
394df22
99ff0d3
4699168
c4b29b0
eddb05e
9f6042c
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -22,7 +22,8 @@ This glossary accompanies the [GitOps Principles](./PRINCIPLES.md), and other su | |
| - ## Reconciliation | ||
|
|
||
| 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. | ||
| Contrary to traditional CI/CD where automation is generally driven by pre-set triggers, in GitOps reconciliation is triggered whenever there is a divergence with [feedback](#feedback) from previous attempts. 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. | ||
| Actions are taken based on policies around [feedback](./GLOSSARY.md#feedback) from the system and previous reconciliation attempts, in order to reduce deviation over time. | ||
|
|
||
| - ## Software System | ||
|
|
||
|
|
@@ -38,3 +39,8 @@ This glossary accompanies the [GitOps Principles](./PRINCIPLES.md), and other su | |
| 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 precautions must be taken to comply with requirements set out in the GitOps Principles. | ||
|
|
||
| - ## Feedback | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I like this addition for the spec on feedback
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. To alphabetize Feedback, I created #41 |
||
|
|
||
| Open GitOps follows [control-theory](https://en.wikipedia.org/wiki/Control_theory) and operates in a closed-loop. In control theory, feedback represents how previous attempts to apply a desired state have affected the actual state. For example if the desired state requires more resources than exist in a system, the software agent may make attempts to add resources, to automatically rollback to a previous version, or to send alerts to human operators. | ||
|
|
||
|
Comment on lines
+43
to
+46
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. To alphabetize Feedback, I created #41 |
||
Uh oh!
There was an error while loading. Please reload this page.