Problem:

The Git repository layout generated by kam is flexible but also fairly complex which steepens the learning curve for adoption it and leads to confusion if not well understood by teams. Furthermore it reuses keywords in paths in the directory tree (e.g. environments/dev/env) which makes it more difficult for users to grasp the structure.

Example: https://github.com/redhat-developer/gitops-repo-example

Goal:

Simplify the Git repository layout and clearly define the boundaries (e.g. entire cluster, apps owned by a single team, single app composed of multiple services, etc) for configurations that belong to a single Git repository.

For example an alternative layout in suggested in Kubernetes docs:
https://kubectl.docs.kubernetes.io/guides/config_management/components/

Other projects outside of GitOps should be able to consume kam as library to creates GitOps layout. Users can add services/components and perform other operations.

Why is it important?

To reduce the complexity of using kam and increase adoption for simple as well as complex applications.

Acceptance criteria:

• Keywords (e.g. config,env, etc) appear only once in a path in directory tree
• Multiple environments are supported in the layout
• Application and service base manifests reside in a single place in the layout
• Environments can overlay application and service base manifests
• Single overlay exist for a single environment (e.g. dev)
• Adding overlay for a service for a particular environment can be done in a single way
• Example environments layout are flat (e.g. prod-east as opposed to prod/east)
• Layout should support the AppStudio directory structure