search

kubevela / catalog

Catalog of community maintained components and traits.
Apache License 2.0
154 stars 145 forks source link

[Important] Revisit the next step of OAM catalog #31

Open resouer opened 4 years ago

resouer commented 4 years ago

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).

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

@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