Skip to content
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

For initial pre-release of GitOps Principles revised by the GitOps Working Group #4

Merged
merged 19 commits into from
May 26, 2021
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
65 changes: 65 additions & 0 deletions PRINCIPLES.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,65 @@
# GitOps Principles v0.1.0

## Summary

GitOps is a set of principles for operating and managing software systems.

When using GitOps, the _Desired State_ of a system or subsystem is defined declaratively as versioned, immutable data, and the running system's configuration is continuously derived from this data.

These principles were derived from modern software operations but are rooted in pre-existing and widely adopted best practices.

## Principles

1. **The principle of declarative desired state**

A system managed by GitOps must have its _Desired State_ expressed declaratively as data in a format writable and readable by both humans and machines.

2. **The principle of immutable desired state versions**

_Desired State_ is stored in a way that supports versioning, immutability of versions, and retains a complete version history.

3. **The principle of continuous state reconciliation**

Software agents continuously, and automatically, compare a system's _Actual State_ to its _Desired State_.
If the actual and desired states differ for any reason, automated actions to reconcile them are initiated.
scottrigby marked this conversation as resolved.
Show resolved Hide resolved

4. **The principle of operations through declaration**

The only mechanism through which the system is intentionally operated on is through these principles.

## Notes

scottrigby marked this conversation as resolved.
Show resolved Hide resolved
### Principle 3 Notes

- These differences could be due to the actual state drifting from the desired state, or the desired state changing intentionally.
- The source of drift doesn't matter. Contrary to CIops, _any_ drift will trigger a reconciliation

### Principle 4 Notes

- We talk here about "regular operations." In an emergency, other modes of operations, e.g. manual intervention, should be considered - followed by a reconciliation of the "tainted" system with the declared state. → resolve the conflict between "GitOps principle" and "I need to deal with problems that GitOps doesn't cover"

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What is considered "tainted"? The statement of "reconciliation of the 'tainted' system does not have a definition. Is 'tainted' a state that is defined by GitOps tool, the action of "manual intervention" or to the modification of the artifact outside the GitOps reconciliation cycle?

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this referring to an emergency temporary disconnection/pause of the GitOps reconciliation cycle to address the "emergency" and then, once the source of truth is updated, continue/reconnect/unpause the GitOps controller for resuming the reconciliations? If that is the case, would it be appropriate to state that a temporary pause of GitOps could happen, and resuming GitOps after that event should be treated like any initial reconciliation cycle where the cycle remediates towards Desired State?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@williamcaban Thanks for this question! This note a little rough. But yes, I think you have a good sense of the spirit it's intending to convey. This may feel repetitive, but here's a quick summary of the intentions for that principle and note:

  • The intention of Principle 4 is to drive home the message that a system managed by GitOps should only be intentionally operated on through principles 1-3.
  • The intention of this note on principle 4 is to acknowledge a caveat to that message: That individuals responsible for incident management may still need to temporarily bypass the normal GitOps process to handle an emergency.

So to answer your question, I think so yes. Typically this happens by:

  1. pausing GitOps reconciliation for a specific subsystem/component
  2. performing emergency actions directly on the system
  3. once addressed, in order to resume GitOps reconciliation, any directly applied "fixes" should be declared in the desired state, and reconciliation should be resumed.

Since these GitOps Principles are meant to be applied broadly – and specific use cases will build on them – we are being very careful not to assume anything about specific systems or tools within the principles or the notes.

If you have a specific proposal for updating the wording for this note to make it more clear, please feel free to propose it using GitHub suggestions directly on this PR. However, since we have already reached broad consensus on this for the initial pre-release, this PR is scheduled for merge very soon. If this PR merges before your suggestion is able to be properly reviewed/incorporated, you may open another PR against main after that point. Also, if you are able, please also join the weekly GitOps Principles Committee Meetings 😄 These are Wednesdays weekly at 19:00 GMT, unless otherwise specified.


## Glossary

- ### Continuous

By "continuous" we adopt the industry standard term to mean 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 between configuration - the desired state - and implementation - the commands, API calls, scripts ... that actually achieve the desired state described in the declarative description.

- ### 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.

- ### Software System

One or more Runtime environments consisting of resources under management.
In each Runtime, management Agents to 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.

- #### State Store

A system for storing versioned, immutable Desired States that provides access control and auditing on the changes to the Desired State. Git may be configured as a State Store, but [special precautions must be taken](recipes/SETTING_UP_GIT.md).