-
Notifications
You must be signed in to change notification settings - Fork 57
Description
How you can help now
-
Please read Dan’s good issue summary (original issue below), which came out of our last group meeting. The gist of the question is, do we think the originally included “closed loop” principle should be added back before the planned v1.0.0 release milestone (scheduled for EOW, no later than Monday Oct 11)
-
We are now asking YOU – WG members & maintainers – to 👍 or 👎 this issue by Friday Oct 8th. (ideally, also comment a short reason).
Note this is not a decision for all time, but just for this first full release. We can continue to discuss for possible inclusion after v1.0.0 if there is too much divergence in opinion. It was left out of RC 1 (see “items left out of this PR”) and not yet included in RC 2 because there was not enough group response so far.
Original issue
This came up as part of an ongoing discussion around #22 with @squaremo @lloydchang @scottrigby @murillodigital.
When we did #21 we removed the closed-loop because we couldn't really articulate why it was there. Some of the discussions referenced above brought back some of the ideas of why we had included closed-loop in the first place.
I'm not very familiar with control theory so the usage of the word "feedback" really threw me off. Feedback seemed like something could happen to your actual state that would then somehow inform your desired state. After going through it with @scottrigby, the way control theory uses "feedback" is that there is a recognition of what is actually occurring in the system and that it is taken into account.
On some level, I think this is encapsulated in two principles "declarative" + "continuously reconciled". With those two ideas, I think you can probably get to closed-loop. For example, if you were to create a progressive delivery plan that involved checking metrics and then making a decision to rollback or move ahead I would view that as part of GitOps as long as it is declaratively expressed and continuously reconciled. The reconciliation implies the idea of closed-loop feedback.
However, as it has come up over and over again and @scottrigby has pointed out, it may be worthwhile making that idea clearly explicit by making it a principle.
For #22 I think we're time boxing to move toward GitOps V1 but if we:
- Believe there is an important value add to bring closed-loop back and
- That we can articulate that value clearly
then we may move ahead to include it in v1. So long as it does not introduce a delay.
In other words: if this is important to you, please fight for it here and give your ideas for how to communicate it.