00:09:06	Scott - CNCF GitOps Working Group:	https://github.com/gitops-working-group/gitops-working-group/discussions/129
00:16:09	Roberth Strand:	Dynamic secrets
00:16:45	Roberth Strand:	I agree with that train of thought
00:19:15	Scott - CNCF GitOps Working Group:	If I get Brice’s point, one thing that can be done is important, dynamically generated state should be written back to the desired state storage as a new immutable version. Is that right Brice?
00:20:30	Brice Fernandes:	@Scott - Yes, that’s the way I see it.
00:22:18	Brice Fernandes:	Note to self: State as test
00:22:33	Scott - CNCF GitOps Working Group:	I think we can distinguish this by that desired state instructions that are required for the system to run properly in the case of a new instance of that system
00:27:57	Scott - CNCF GitOps Working Group:	4. The principle of “we really mean it”. It’s not that human operators won’t still interact with a system directly, but that would be outside of GitOps practice?
00:32:18	Scott - CNCF GitOps Working Group:	Any other change in the system apart from principles 1-3 are not recommended and fall outside the scope of GitOps.
00:32:34	Scott - CNCF GitOps Working Group:	Here we could have a note about “break glass” or “emergency break” etc
00:33:47	Jesse Butler:	Taking a run at #4:
00:33:48	Jesse Butler:	The primary interface to drive configuration change in the system is through the creation of a new declarative version of the desired state, not through interaction with the running state of the system.
00:35:04	Roberth Strand:	The principle of no-touchy
00:35:18	Jesse Butler:	No-touchy, we mean it
00:35:25	Scott - CNCF GitOps Working Group:	I like it. What about “…not through any other method of adjusting the actual state of the system”
00:35:53	Roberth Strand:	I agree
00:38:27	Chris Sanders:	I could go with #4 wording as is.
00:39:00	Schlomo Schapiro:	The beard comes off on Friday :-)
00:39:58	Roberth Strand:	The main interface to the system, as wording, rather than mechanism through which change...
00:40:03	Chris Sanders:	"state change"
00:40:05	Roberth Strand:	Perhaps?
00:40:28	Jesse Butler:	I used “primary” to admit some things won’t align (see also: continuous)… bu the intent is only
00:40:50	Christian Hernandez:	Is that like "yak shaving"?
00:40:59	Jesse Butler:	kinda. Different tshirts.
00:40:59	Roberth Strand:	Just harder
00:41:12	Roberth Strand:	Yaks yield
00:41:21	Jesse Butler:	“Can be intentionally managed” ?
00:41:36	Jesse Butler:	Or “is intentionally managed”
00:41:49	Scott - CNCF GitOps Working Group:	“Intentionally” 👍
00:42:00	Chris Sanders:	rather than "configuration" I would stay with using "state" to be consistent throughout the principles
00:42:12	Scott - CNCF GitOps Working Group:	Jesse “is” imo
00:42:17	Scott - CNCF GitOps Working Group:	Chris I agree 👍
00:43:28	Roberth Strand:	The first new proposal makes much more sense to me for the fourth principle
00:43:45	Roberth Strand:	First one in the document
00:43:52	Jesse Butler:	At least we aren’t writing a spec or RFC!
00:44:30	Moshe Immerman:	maybe just add a footnote on what we mean by state
00:44:55	Scott - CNCF GitOps Working Group:	Moshe I agree. It’s important to have a place for notes on each principle
00:45:01	Roberth Strand:	My ADHD don't allow me to think out coherent sentences while listening :D
00:45:01	Leonardo Murillo:	"The only mechanism through which a system can be intentionally managed by a human operator or another system is through new versions of declared state"
00:46:13	Chris Sanders:	For #1: instead of "must have" use "always has"
00:46:31	Chris Sanders:	To get to Schlomo's point
00:47:04	Christian Hernandez:	I'm still a fan of keeping #4
00:48:27	Schlomo Schapiro:	I suggested scrapping #4 as a way to figure out what it actually contains. Like from a legislative perspective, what "bad stuff" would be permitted in the absence of #4
00:48:31	Brice Fernandes:	I concur with Jesse Regarding the necessity of #4
00:48:49	Brice Fernandes:	Also agree that it’s not logically required.
00:48:58	Chris Sanders:	good points for keeping #4 as key emphasis
00:49:01	Moshe Immerman:	+1
00:49:08	Jesse Butler:	Good call Schlomo
00:49:13	Schlomo Schapiro:	I agree also with having #4 as a summary, but then I actually like the long version with the (x) items
00:53:04	Chris Sanders:	succinct is good
00:53:12	Brice Fernandes:	@Schlomo - Definitely feel like there should be additional notes attached
00:54:02	Roberth Strand:	I think most (or all) points have been made
00:56:22	Jesse Butler:	I liked what I heard enough to scare my cat with an "ooh!"
00:58:54	Scott - CNCF GitOps Working Group:	Sorry I thought it was Leonardo. Thanks Jesse
00:59:15	Christian Hernandez:	Anytime I hear "robot" I think: "They took our jerbs!"
01:00:52	Jesse Butler:	That’s where “primary” cam ein
01:01:12	Scott - CNCF GitOps Working Group:	“should be” instead of “can be”?
01:02:10	Roberth Strand:	21:59...
01:02:26	Jesse Butler:	I can go 5 mins more
01:02:30	Jesse Butler:	Same haha
01:03:06	Scott - CNCF GitOps Working Group:	Robert I agree with that
01:04:28	Schlomo Schapiro:	I propose a vote: E
01:04:48	Scott - CNCF GitOps Working Group:	PROPOSAL A:

The only mechanism through which a system can be intentionally managed by a human operator or another system is through (creating a) new versions of declared state

PROPOSAL B:

The only mechanism through which which a system can be operated on is through the creation of a new version of the _Desired State_

PROPOSAL C:

The interface to (drive configuration change in the system|modify the system) is through the creation of a new declarative version of the desired state, (not through interaction with the running state of the system|…not through any other method of adjusting the actual state of the system).

PROPOSAL D:

Merge with #1

PROPOSAL E:

The only mechanism through which a system can be intentionally operated on is through these principles.
01:05:01	Schlomo Schapiro:	I vote E
01:05:40	Scott - CNCF GitOps Working Group:	“The mechanism”?
01:07:56	Christian Hernandez:	Sorry I have to drop
01:08:09	Jesse Butler:	Same, +1 Scott. Thanks all!
