[Important] Revisit the next step of OAM catalog

[resouer]

In general, there're two main features of OAM as a model:

1. Standard application definition for Kubernetes. This is very similar to Application CRD but with extra benefits:
   • A DevOps workflow with separate concerns - e.g. Operational Capabilities as Service
   • Manageability for ops capabilities (trait) - register, discover and conflict detect
     • kubectl get traits
     • For given component, one could directly tell out how many ops capabilities are bound to it (by yaml file, and by kubectl tree)
   • More information: kapp, and GC
2. A framework to build abstractions (for either workload or trait).
   • composition/decomposition
   • automatic workloadRef (or ownerRef)
   • "break the abstraction" (auto-inject childResource)? See: https://github.com/oam-dev/catalog/issues/31#issuecomment-648435855
   • anything else?

As K8s standard app definition:

We need to make sure ANY existing k8s resource can be defined as trait/workload/scope with zero effort. /cc @zzxwill I'd suggest modeling every application you can find in cloud native community, for example: https://github.com/istio/istio/tree/master/samples/bookinfo by OAM and put the example YAML in catalog/applications or somewhere else. Please work with @szihai on this.

Open question: how to handle xxxDefinition in this case? Let's create a tool (e.g. cli)?

kubectl oam definition-gen --all
kubectl oam definition-gen service deployment statefulset

As an abstraction framework:

Traits in OAM should be mostly external capabilities or higher level abstractions for built-in capabilities, not "translation" of k8s built-in api resources. I've raised similar concern in https://github.com/oam-dev/catalog/issues/26#issuecomment-645595071.

Similarly, workloads should come from wider community like Terraform/Crossplane, not StatefulSet, Deployment etc.

For instance, it's less valuable to create a ServiceExpose trait which simply removed label selectors - user should define k8s service as trait freely. workloadRef is an internal helper for building abstractions yet itself is not "better user experience".

A perfect example of how a trait is defined is Ingress API v2: https://containo.us/blog/kubernetes-ingress-service-api-demystified. Though there are still opportunities like Route, Blue-green/Canary, monitoring, logging and many. What's still missing in Kubernetes today?

Building abstractions with zero effort is important, decomposition/composition is great and we also need to improve its UX. /cc @wonderflow

[resouer]

A related issue: whether we need to make k8s built-in capabilities work for ContainerizedWorkload?

There are two scenarios actually:

1. The capabilities in Deployment like VolumeMounter. It should go with decomposition/composition.
2. The capabilities which only works for Deployment like HPA. The issue is its targetRef, so we could probably auto-inject childResource to it (it's a common pattern for any other higher level abstraction).

[zzxwill]

As catalog is the recommended repo for OAM components/traits/applications, how about we moving proper Apps from oam-dev/samples to application folder?

[resouer]

@zzxwill I agree catalog/applications could be categories as "user stories", similar to https://github.com/tektoncd/catalog . Though we don't need to touch oam-dev/samples - this is where official demo apps live.

One example is:

catagory
├── applications
│   ├── knative
│   ├── kubernetes # show off how to generate definitions and 4-5 examples of popular k8s apps
│   ├── openfaas
│   └── ...
├── workloads
│   ├── terraform # 1000+ workloads generated from Terraform modules
│   └── ...
├── traits
├── scopes

/cc @wonderflow