When I read closed loop I immediately think of https://en.wikipedia.org/wiki/Control_theory#Open-loop_and_closed-loop_(feedback)_control

Most GitOps implementations are open reconciliation loops, the change is applied irrespective of the target state and the success or failure of the operation does not feedback into Git. Some GitOps products e.g. Argo do try and build closed loops based but their feedback is internal only (either via UI or events) - Will open a new PR on this topic as I think it is an unsolved problem

It's true the Current State doesn't feedback to the Desired State store, but it does feed back to the Software Agents so they know how the current and desired states do or do not diverge. This part of that wikipedia page you linked sounds like a correct description to me, where the "controller" map to GitOps Software Agents :

The definition of a closed loop control system according to the British Standard Institution is "a control system possessing monitoring feedback, the deviation signal formed as a result of this feedback being used to control the action of a final control element in such a way as to tend to reduce the deviation to zero."

WDYT?

I find this change too.. nerdy. While true, the original sentence "clicks" with most heads and does not sound too niche.

Technically this is not true. Many crypto systems are explicitly defined not to be configurable. I don’t equate hard coded with configuration, unless you include reflection or AOP or pointer hacking, etc.

You cannot talk about any non-trivial system, without talking about the human element, they are one and the same

GitOps is a structured mechanism for humans to interact inside the system, not with - the distinction is subtle but vital nevertheless.

GitOps makes sense in environments that have a healthy balance between the human and technical elements. while most sales processes are heavily weighted towards human interaction, it is not unforeseeable that some exist where GitOps makes sense.

e.g. A sale in progress could require a new environment bet created, and then promoted through various levels of priority, security and reliability on its way into production.

I do think that GitOps also makes sense in environments that don't have a healthy balance yet.
There, GitOps can act as an agent that reconciles the mismatch. ;)

I second this sentiment. (Good link about socio-technical systems too.) I wanted to make sure that the scope excluded human decision making explicitly. I've re-worded to reflect this and make it clearer. Do you think the meaning is clearer and more accurate now?

I appreciated the original statement in line 83 and found it valuable/clarifying to directly callout the separation between our intent, the principles and a specification. It also addressed a small question with the inclusion of software development because most GitOps discussion revolves around operations (delivery/reconciliation). If I change the source code of a system to account for new business logic I believe that change falls under the umbrella of GitOps because now the systems run state will be altered with its next delivery.

Ultimately, that change is part of the system and should be captured, even if its delivery is peformed through another change that identifies packaged software to be executed. Most information I read is heavily weighted on Ops, do others agree that GitOps reaches this far left to commits of application source code? If so, should it be called out in the scope?

@kmb385 currently this idea is captured in a few places in this PR (specifically "systems" or "subsystems"). Does this address your concern?

Here:

By "Configuration", we mean data that defines how a system or subsystem should behave.

For example, the same web server code may be running on thousands of different servers managed by hundreds of different companies.
The behaviour of an individual webserver will differ based on how it is configured.
Configuration data is typically in the form of files or arguments to a computer program, but some systems may also currently use configuration databases or remote configuration services. Configuration also includes data about what version of code a software system should run, so software version information is also considered configuration.

Together, the aggregate of all configuration data for a system form its "Desired State". The "Desired State" of a system is defined as data sufficient to recreate the system from nothing so that instances of the system are behaviorally indinstinguishable.

Also here:

The definition of a system can be quite broad, and may incorporate human as well as programmatic processes.
For example, is a company's sales process a system?
Should GitOps be applied to it?
Although a vision in which the GitOps practices are applied generally to all processes, human or otherwise is compelling, a more pragmatic approach is preferable, to avoid the risk of attempting to "boil the ocean".

Instead, we should focus on subsystems where the Desired State is well defined, implement the GitOps principles there, and grow out to capture more systems from that initial subsystem.

The PR also retains this from the README:

GitOps is fast becoming the methodology of choice for operating modern cloud native infrastructure and applications

@scottrigby It does, I'm very new to the project and reading the definition of "software system" in the definitions section really helped. My interpretation of that definition is that it does include the application source code.

I think this is confusing in the context of application data. If I really wanted to recreate an entire system I'd have to consider recreating the application data that it requires to operate, and may even be interpreted in the context of disaster recovery (is GitOps a way to recover the latest known state of a system should disaster strike?) This also moves the conversation into scenarios that are perhaps beyond configuration, for instance, should DB migrations be declared as part of the desired state, and should I want to recreate a system matching that state must GitOps guarantee db schema consistency?

Definitely should mention that DB Migrations Question in a FAQ on the Website. Will be a commonly asked question.

is GitOps a way to recover the latest known state of a system should disaster strike?

The latest configured behaviour? Yes. The latest state including application data? Not at this time.

Definitely should mention that DB Migrations Question in a FAQ on the Website. Will be a commonly asked question.

👍 That's a super common discussion.

system matching that state must GitOps guarantee db schema consistency?

I think so, although this is genuinely difficult currently. Or rather, the db schema at a point in time should be declared. Moving to that schema from some arbitrary starting point is detail left to the reconciling agent. Currently, this will be in the form of a set of unidirectional migrations generated manually. That's an implementation detail though.

I agree that we should mention application data here though.

@murillodigital wrote:

should DB migrations be declared as part of the desired state?

Yes.

@murillodigital wrote:

must GitOps guarantee db schema consistency?

Should instead of must.

GitOps should guarantee database schema consistency.

@bricef wrote:

I think so, although this is genuinely difficult currently. Or rather, the db schema at a point in time should be declared. Moving to that schema from some arbitrary starting point is detail left to the reconciling agent. Currently, this will be in the form of a set of unidirectional migrations generated manually. That's an implementation detail though.

Agreed that database schema at a point in time should be declared.

Database migrations should be generated automatically, instead of manually.

Examples of implementation details:

1. Ask HN: How does your development team handle database migrations?
2. Evolutionary Database Design by @pramodsadalage and @martinfowler at @thoughtworks using tools such as:
   • https://github.com/liquibase/liquibase by @liquibase and @Datical
   • https://github.com/flyway/flyway by @flyway and @red-gate
   • https://github.com/mybatis/migrations by @mybatis
3. https://github.com/schemahero/schemahero by @schemahero, donated by @replicatedhq to @cncf

From GitOps Principles Committee - April 14, 2021 after 40:50

@bricef said:

It's more about an aspirational direction, not necessarily what we do right now.

Agreed.

@tonit wrote:

DB Migrations Question in a FAQ

Agreed.

Not sure I follow this in the context of application configuration vs platform configuration as desired state. For instance, I may have some state in which I hold the declaration that I need some service running or crd available in which my application will depend (and maybe other applications as well), and some other state in which I specify the runtime parameters for one such specific application (say, endpoints or other runtime specific configuration for the application itself) - not sure its the best example but the point is, as part of a system there may be platform components as well as application components that will be interrelated, and following this statements it seems the argument is, anything that is somehow interrelated should be declared in the same state store. I think that such interpretation would be in the least not realistic.

Also I'd change real software systems to production software systems or distributed systems, can't think of a surreal or imaginary software system 😆

😄 Indeed.

the point is, as part of a system there may be platform components as well as application components that will be interrelated, and following this statements it seems the argument is, anything that is somehow interrelated should be declared in the same state store. I think that such interpretation would be in the least not realistic.

I agree that for all practical purposes, this is currently unrealistic, but the general point still stands. It is desirable to have all of a system's configuration in a single state store. I think changing "insufficient" to "undesirable" may be better. Do you think that's sufficient @murillodigital?

the point is, as part of a system there may be platform components as well as application components that will be interrelated, and following this statements it seems the argument is, anything that is somehow interrelated should be declared in the same state store. I think that such interpretation would be in the least not realistic.

I agree that for all practical purposes, this is currently unrealistic, but the general point still stands. It is desirable to have all of a system's configuration in a single state store. I think changing "insufficient" to "undesirable" may be better. Do you think that's sufficient @murillodigital?

How about changing the approach from that which is undesirable or suboptimal to that which is ideal:

Ideally, the configuration for all interrelated components of a system should be stored in a single state store, in order to have a concise and consolidate view across all components that may have be subject to overarching behavior.

Or something along those lines? @bricef

How about changing the approach from that which is undesirable or suboptimal to that which is ideal

@murillodigital I like this approach flip

Should a GitOps compliant system ALWAYS reconcile on identified drift or are other mechanisms possible to "close the loop" (alerting or otherwise?) I think this may be a barrier to a lot of organizations at some initial degrees of capability, although I agree this should be the desired behavior. I guess an automated action could be an alert which triggers a human-lead attempt to reconciliation...

"Manually Closing the Loop". Definitely a FAQ point for the website.

I think desired state should also include the policy for when reconciliation is allowed to happen.

I desire changes to Y to only occur during change windows, rollback on A, remediate on B and alert on C
I desire X to be Y

Guess this is along the lines of my previous comment.

Isn't this incorrect? A software agent WILL interact with the system to apply the declaration that the human committed to the state store? (think an operator in a cluster)

I think we should look for an example more consistent with cloud native architecture and operational practices, this is not a realistic, dynamic horizontally scaling scenario of ephemeral resources, which would most likely be more applicable to the use cases that will be looking to adopt GitOps.

I do think this is still reality. And when "selling" those low-tech firms the cloud-native cool-aid, GitOps-like practices are one of the showcases that really go well.
I agree another example for existing cloud architectures would make sense, too (as an addition).

Concur. A better example would be a welcome here.

@murillodigital do you want to propose an additional, cloud native example?

How about we consider the following example authored by @TomOnTime?

Thank you @murillodigital @tonit @bricef @scottrigby @moshloop @TomOnTime.

There's a very specific reason why that term is used, but the context for it is poor. I'll reword that paragraph to be clearer.

@murillodigital does this paragraph reword make more sense now?

I find this change too.. nerdy. While true, the original sentence "clicks" with most heads and does not sound too niche.

Definitely should mention that DB Migrations Question in a FAQ on the Website. Will be a commonly asked question.

"Manually Closing the Loop". Definitely a FAQ point for the website.

I do think this is still reality. And when "selling" those low-tech firms the cloud-native cool-aid, GitOps-like practices are one of the showcases that really go well.
I agree another example for existing cloud architectures would make sense, too (as an addition).

Proven is a strong word, and I think we should wait until there is academic research that proves this

@moshloop Are you saying you find these resources to be not credible?

Is this a sufficient change (less focus on "proven"), and keep the rest otherwise the same?

- Operationally, it has been proven time and time again…
+ Operationally, consensus continues to grow that…

This is not true of ML systems. Human understanding or even observability is an area of ongoing research. Definitely not consensus yet. Growing, maybe. Desirable yes.

But GitOps can't be "used as a guiding principle", it's a practice guided by a set of principles. The intention of this PRINCIPLES doc is to define those.

Otherwise I like the rest of this suggestion 👍

I strongly disagree with this line. GitOps is all about human decision-making, i.e. a human deciding to make a change to a system and another human deciding that the change is of low enough risk to be merged.

Part of the areas needing improvement is how human-decision making can be augmented by a better understanding of how a change could affect a system. (Tests / linting play a role here but usually disconnected from the system) i.e Will scaling down cause production workloads to be evicted or scaling up exceed my organizational budget

GitOps also has scaling problems in large organizations, and one of the goals of the WG should be to try and solve them e.g.

• How do multiple teams in an organization interact on a single repo,
• How is a system decomposed into multiple repositories
• How are systematic changes across systems and repo's implemented and monitored
• How are changes promoted through environments while respecting change windows and organizational change policies.

If I understand your comment correctly, this is not what was meant here. This is to clarify that the scope of GitOps is to define and reconcile technical systems, not human systems. Humans are always on some level in control of the automated processes. No HAL or Skynet here LOL 😛 But seriously, we could probably word this better.

Not sure how this could even be attempted using GItops?