"manually update desired state files or environment… glaring issue"

[lloydchang]

Has the following "manually update desired state files or environment… glaring issue" been acknowledged and addressed yet?

Quoting https://www.reddit.com/r/kubernetes/comments/eku68p/comment/fdfak4z/

When I evaluated GitOps (a year or more ago, which is forever in the state of these things, I'll admit), the movement seemed to assume that we would be willing to manually update desired state files or environment, which is completely contrary to how Continuous Deployment should work. Maybe the world has moved on, and they've solved this glaring issue, but at the time the communities involved didn't even seen to acknowledge this as a problem.

[chriswolske]

I think I understand the concern, but I also think this is a philosophical "prime mover" question. The question makes it sound like there will be dozens/hundreds/thousands of desired state files that need to be manually updated and of course nobody wants that.

There are several potential ways to address this: the use of templates to build the desired state files or an Operator are two that come to mind. Depending on how the request for change originates, this could be an update/PR pushed by a service-management/ticketing system. At some point, someone has to make the desired change known to the system, and this is going to need to be manual (I'm not going to be the first one signing up for a brain-interface just to avoid this step...)

I think the key thing is that a declarative state is defined and versioned in the repo. It might seem like an unnecessary step, but making as much of that declaration as specific and human-readable as possible is desirable (ie. not burying it in references to shared-definitions, which would then need to be checked to see what version they were when invoked, etc).