How do we handle target reference fields and labels?

[resouer]

In OAM, the target reference fields or label selectors do not make a lot sense. For example, consider these traits below:

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  selector:
    app: MyApp

apiVersion: autoscaling/v2beta2
kind: HorizontalPodAutoscaler
metadata:
  name: php-apache
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: php-apache

All these label selector and scaleTargetRef can be generated by OAM runtime since OAM clearly know which workload it bound to (AWS folks call this "intention driven").

So the question is can we do and will we do this for users?

Several approaches if we want to do this:

1. Write a CRD controller to generate them. For example, a trait named Expose.
2. Enumerate k8s resources and handle them one by one.
3. Placeholder on the object (not good for oam-runtime but should work for app engine's template object). For example:

   scaleTargetRef: \$(OAM_WORKLOAD_REF) # or defined in parameters list
   ...
   podSelector:
     matchLabels: \$(OAM_WORKLOAD_LABELS) # or defined in parameters list
   

Any thoughts? @hongchaodeng @wonderflow @zzxwill @ryanzhang-oss

[wonderflow]

For scaleTargetRef case , we already have such mechanism, using workloadRef in TraitDefinition will help oam-runtime to bind workload automatically.

For label seclector case, I suggest we generate unified labels for all resources generated by oam-k8s-runtime. For example: application.core.oam.dev=<app-name>

[resouer]

@wonderflow this issue is about whether we want to inject (and how to inject) such information to user brought capabilities (Service, HPA, their own Operators etc), so they don't need to define these fields/labels manually. workloadRef and generate labels won't help in this case.

[hongchaodeng]

The reason why k8s has labeling and object reference in the first place is because it is designed to be loosely coupled resource model:

1. Labeling is designed to organize and group resources.
2. object ref is to work around the lack of indexing in APIServer. Think of it as an alternative to Foreign Key.

For 1), OAM has provided an application centric structure to organize resources, which is higher level than labeling. We should definitely replace labeling and handle labeling and selector for users.

For 2), it is already a flaw in APIServer design. We should definitely hide it from users.

[resouer]

@wonderflow That being said, it's indeed necessary to automatically add labels to OAM workloads and traits. Could you please raise a separate issue for this? I'd guess https://kubernetes.io/docs/concepts/overview/working-with-objects/common-labels/ could be considered.

[wonderflow]

@resouer sure, I'm considering to write a proposal for that