OpenGitOps repo structure

[scottrigby]

Question

OpenGitOps is a CNCF Sandbox project for lasting programs, documents and code from the GitOps Working Group.

How should the OpenGitOps sandbox project repos be structured?

Proposed structure

Repos:

• project: The entrypoint repo for the OpenGitOps project. Including an entrypoint README, governance, MAINTAINERS file, and other top-level information about the project. Note these repos for CNCF projects are sometimes named "community", etc. However there is precedent for project (containerd), and for OpenGitOps this may be semantically useful to clearly distinguish that this is for the project rather than for the GitOps Working Group

• documents: Example documents (see original GitOps WG Charter document):

  • GitOps definition and terminology document
  • GitOps methodologies and approaches document
  • GitOps landscape document
  • Working examples for getting started

  Note that a "definition and terminology document" is being worked on by the GitOps Principles Committee as the "Principles" (which includes a definition of GitOPs at the beginning), and a planned Glossary. The principles plan to reference the glossary when necessary, so it may make sense for these to be colocated in the same repo so we can release versions of these together.

• website: hugo (etc) code for opengitops.org (or whatever canonical project domain that all the other TLDs point to Nominate Jaime Magiera for Maintainer #111), can pull in content from the documents repo, etc.

• code: placeholder for future code for "interoperability between tools" (could add later when we get to this)

• programs: placeholder repo. Example future programs may be for "conformance, and certification" (could add later when we get to this)

Then if any individual programs, code projects or documents require separate repos for some reason we can always do that and link to those.

Timeline

We don't need to set this in stone, but I have a task to move work by the principles committee into the OpenGitOps project GitHub org, so I needed a named repo to add this, so making this discussion for transparency. We can also discuss at the next working group meeting.

[roberthstrand]

We can also discuss at the next working group meeting.

Sounds like good enough time to give this a think. I don't see any issues with the proposed structure, at least not at the moment. This is usually how it works, up until the point where someone points out something 😊

[lotharschulz]

LGTM 👍 . I was thinking of an additional events placeholder repo to list GitOps events and talks. We could add this later.

[scottrigby]

The OpenGitOps repo structure is in place. See the list at https://github.com/open-gitops/project/blob/main/README.md#repositories

[lloydchang]

@scottrigby wrote:

code: placeholder for future code for "interoperability between tools" (could add later when we get to this)

---

While I was reviewing:

GitOps Working Group - Overview and Invitation.

Video referenced https://github.com/podtato-head/podtato-head/ for the purpose of 📨🚚 CNCF App Delivery SIG Demo.

From https://github.com/podtato-head/podtato-head/blob/main/README.md

Project pod tato Head
Podtato-head demonstrates cloud-native application delivery scenarios using many different tools and services. It is intended to help application delivery support teams test and decide which mechanism(s) to use.

Considering the above: If code is created for "interoperability between tools", then it should start at https://github.com/podtato-head/podtato-head

WDYT?

Thank you!

[roberthstrand]

There are many examples that can be set up using podtato head, for sure. Some examples are already set up through general App Delivery work, some might pop up from the cooperative delivery WG and we can absolutely contribute to that from the GitOps WG. I also think we could separate some and deliver it through the OpenGitOps website, but still reference the podtato head application. It was created as a workload we can use in examples, so why not use it 😊