Better support for Kubernetes built-in resources

[resouer]

Most of the community users of oam-kubernetes-runime tend to get start OAM with Kubernetes built-in resources rather than plugin capabilities. We should create a better experience for them. Let's use this one as a parent issue.

1. Generate definition objects for common K8s built-in resources by default. A good example of "common resources" is what's listed by default in https://github.com/vmware-tanzu/octant. @zzxwill
2. Better story of Secret to work with OAM dataInput/dataOutput. A "auto injection" experience would be great. One quick idea is can we define Secret as trait? @hongchaodeng
3. Intention driven: add default labels to Deployment (and other common workloads) and maybe even auto-generate labelSelector for Service (and other similar common traits) and deprecate ServiceExpose: https://github.com/oam-dev/catalog/tree/master/traits/serviceexpose. @wonderflow
4. Intention driven: similar to 3 but applies to even non-k8s built-in resources. For example, for Flagger Trait, users do not need to write targetRef and just let OAM to inject this field. This should already be supported by https://github.com/crossplane/oam-kubernetes-runtime/pull/46/files @ryanzhang-oss

Intention driven means the app definition reflects users' intention directly, for example, bound certain traits to component. So users do not need to take care things like labelSelector, targetRef etc - they only focus on defining meaningful fields in workload/trait.

Anything else? Any feedback from community is welcome!

[hongchaodeng]

Generate definition objects for common K8s built-in resources by default.

There should be a "root" WorkloadDefinition and TraitDefinition by design. Any k8s built-in resource could be modeled as one of the types. If runtime couldn't find an explicit definition, it will point to the root implicitly.

Better story of Secret to work with OAM dataInput/dataOutput. A "auto injection" experience would be great. One quick idea is can we define Secret as trait?

This is two orthogonal issues. First, having a Secret trait would be a great add-on from operational experience. Second, auto injection has nothing to do with Secret, but more about object definition mapping. This needs more use case input before we have a final design.

[resouer]

First, having a Secret trait would be a great add-on from operational experience. Second, auto injection has nothing to do with Secret, but more about object definition mapping. This needs more use case input before we have a final design.

The alternative is "auto-injection" could be achieved in app engine layer so oam-k8s-runtime will be left as-is for lower level primitives. (/cc @wonderflow correct me if I'm wrong)

[wonderflow]

@resouer "auto-injection" can achieved at app engine layer, but I think it's better if oam-k8s-runtime could have this ability.

I don't think Secret trait is good idea as we already have service binding trait which can contain secret as a kind of source. What I hope to see is a better design for service binding trait to have the "auto-injection" ability.

Let's have a quick summary for service binding design here. The main idea for service binding is we leverage K8s webhook to mutate object before they are really created or updated. The mutate logic is written in service binding controller. We have to write different logic code for different workloads and resources.

I hope oam-k8s-runtime can integrate with service binding trait better, at least these goals should be achieve: \cc @hongchaodeng

1. The webhook mutate of service binding should be done by oam-k8s-runtime. We should design some mechanism like patch trait to let oam-k8s-runtime know how to do mutation.
2. We should use configuration instead of writing code to support more kinds workloads and resources to do service binding.

[hongchaodeng]

I don't think Secret trait is good idea as we already have service binding trait which can contain secret as a kind of source. What I hope to see is a better design for service binding trait to have the "auto-injection" ability.

I would like to rectify the naming here first. The name of the feature should be called Secret Binding. Service Binding means connecting a service to another service without knowing the details of where to get the connection credentials. For example, binding a Spring Web App to a PostgreSQL DB. On the contrary, what we are discussing here is focused on Secret, and to integrate the secret into a Workload Type (e.g. Deployment).

First of all, I'm not quite sure if it provides any value from such integration. More evidence and data are needed to demonstrate necessity of this feature.

Even if it does, it won't be something like Patch Trait. The design would be much simpler since we can assume Workload schema should provide a PodTemplate and then inject the Secret in a standard manner. This would align better with the upstream community.