Avoid vendor lock-in through tooling or standards

[tonit]

In the Working Group Call of February 11th it was mentioned that of cause many things GitOps includes is not stored in git. Say this Discussion, Pull Requests, Issues.

Now the discussion I want to open:

• Is there an existing tooling (market?) for avoiding those lock-ins? Say cross-platform PRs?
• Is there any desire (here?) to create APIs for vendor-independent "GitOps"?

[bricef]

We didn't really have time to go into it during the meeting but my take is that whilst important, these matters aren't the core of GitOps, they're implementation details.

The ideas of GitOps itself are tool-agnostic, but actual implementations are not. The "Git" in "GitOps" is an implementation detail. GitOps isn't about Git, not really. "GitOps" is about Declarative state management with continuous reconciliation. You can use Git to store the state (I personally love Git) but you can also use an append-only filesystem, a blockchain or a proprietary solution. Using vendor-specific features is just fine.

In addition, the scope of GitOps is operating software systems. How humans make decisions and come to a consensus is very much outside of the scope of GitOps. Where and how decisions about software systems are recorded is as far as GitOps goes.

This doesn't mean I'm personally unsympathetic to the notion of using exclusively open standards and tools, or of creating common abstraction layers, just that GitOps doesn't really have a lot to say about this because those concerns are out of scope.

[bricef]

A "GitOps Standard" or "GitOps Specification" could be much more opinionated on the subject though. As could common patterns that we prepare and use as examples.

[lloydchang]

@bricef asked:

Say cross-platform PRs?

This relates to https://github.com/gitops-working-group/gitops-working-group/discussions/76#discussioncomment-633924

Thank you @bricef