[Feature] Automatically fill correlation fields for users

[hongchaodeng]

Currently, if we want to deploy an OAM app, it still requires filling fields like label selector or serviceName:

apiVersion: core.oam.dev/v1alpha2
kind: ApplicationConfiguration
metadata:
  name: example
spec:
  components:
    - componentName: web
      traits:
        - trait:
            apiVersion: v1
            kind: Service
            metadata:
              name: web
            spec:
              selector:
                app: web
              ports:
              - port: 80
        - trait:
            apiVersion: extensions/v1beta1
            kind: Ingress
            spec:
              rules:
              - http:
                  paths:
                  - path: /
                    backend:
                      serviceName: web
                      servicePort: 80

The label selector in Service and serviceName/Port in Ingress could be automatically inferred in the context of appconfig. A user should ultimately save the effort and just write:

apiVersion: core.oam.dev/v1alpha2
kind: ApplicationConfiguration
metadata:
  name: example
spec:
  components:
    - componentName: web
      traits:
        - trait:
            apiVersion: v1
            kind: Service
            spec:
              ports:
              - port: 80
        - trait:
            apiVersion: extensions/v1beta1
            kind: Ingress
            spec:
              rules:
              - http:
                  paths:
                  - path: /

[resouer]

@hongchaodeng one possible solution may be "mark" the selector filed path in definition object and let OAM runtime to inject required information (similar to a patch trait).

[ryanzhang-oss]

I think these two cases are actually different. In the first "serviceTrait" case, the trait can discover the labels from the workload it attaches to. In the second "ingress" case, the trait needs to know the information of another trait applied to the same workload. This probably needs some explicit data dependency injection which seems to look even more cumbersome.

[resouer]

@ryanzhang-oss The second case is actually not a dependency issue, it's a discover issue. I'd propose OAM runtime automatically generate Services for a given component based on its revision history and expose all its ports. Let's say below component has 2 revisions:

apiVersion: core.oam.dev/v1alpha2
kind: Component
metadata:
  name: frontend
spec:
  workload:
    ...
    spec:
      image: nginx
      port: 80

$ kubectl get deployments
NAME
frontend-v1
frontend-v2

Then three Services should be in the system

$ kubectl get svc
NAME
frontend      # this one always select the pods labeled by "frontend
frontend-v1   # this one only select pods labeled by "frontend and "v1"
frontend-v2   # this one only select pods labeled by "frontend and "v2"

So traits are free to use these Service names to do their job.

This is closely related to https://github.com/crossplane/oam-kubernetes-runtime/issues/174

[resouer]

Btw, for end users they should not use ingress or service at all. So the target solution for this issue should focus on how to let users plug-in their own traits with zero effort.

Another missing use case we should also cover is: targetRef , related to: https://github.com/crossplane/oam-kubernetes-runtime/issues/107