oam-kubernetes-runtime icon indicating copy to clipboard operation
oam-kubernetes-runtime copied to clipboard

[Feature] Propagate labels of non-core workloads to pod template

Open zzxwill opened this issue 5 years ago • 5 comments

Is your feature request related to a problem? Please describe.

In order to implement feature https://github.com/crossplane/oam-kubernetes-runtime/issues/174, not only could labels of ContainerizedWorkloads be propagated to its pods (implemented in https://github.com/crossplane/oam-kubernetes-runtime/pull/175), but also should work for non-core workloads, like Deployment.

Deployment workload's customized labels like component.oam.dev/name: example-deployment could be automatically generated for its pods.

  • component yaml
apiVersion: core.oam.dev/v1alpha2
kind: Component
metadata:
  name: example-deployment
spec:
  workload:
    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: nginx-deployment
      labels:
        app: nginx
        component.oam.dev/name: example-deployment
    spec:
      selector:
        matchLabels:
          app: nginx
      template:
        metadata:
          labels:
            app: nginx
        spec:
          containers:
          - name: nginx
            image: nginx:1.17
            ports:
            - containerPort: 80
  • appconfig yaml
apiVersion: core.oam.dev/v1alpha2
kind: ApplicationConfiguration
metadata:
  name: example-deployment-appconfig
spec:
  components:
    - componentName: example-deployment

The pod haven't get the customized label.

✗ k describe pod nginx-deployment-5d85b5fb59-vmkdz
Name:         nginx-deployment-5d85b5fb59-vmkdz
Namespace:    default
Priority:     0
Node:         kind-control-plane/172.18.0.2
Start Time:   Wed, 26 Aug 2020 14:59:02 +0800
Labels:       app=nginx
              pod-template-hash=5d85b5fb59
Annotations:  <none>
Status:       Running
IP:           10.244.0.9
IPs:
  IP:           10.244.0.9
Controlled By:  ReplicaSet/nginx-deployment-5d85b5fb59

zzxwill avatar Aug 26 '20 07:08 zzxwill

This should not be an issue as user can fulfill their config if they use non-core workloads.

In this case, you could write component like this:

apiVersion: core.oam.dev/v1alpha2
kind: Component
metadata:
  name: example-deployment
spec:
  workload:
    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: nginx-deployment
      labels:
        app: nginx
    spec:
      selector:
        matchLabels:
          app: nginx
      template:
        metadata:
          labels:
            component.oam.dev/name: example-deployment
            app: nginx
        spec:
          containers:
          - name: nginx
            image: nginx:1.17
            ports:
            - containerPort: 80

wonderflow avatar Aug 26 '20 08:08 wonderflow

Cool, you are right. Thanks.

zzxwill avatar Aug 26 '20 13:08 zzxwill

@wonderflow Note that for non-core workload it still need revision labels to be automatically patched (not propagation).

resouer avatar Aug 26 '20 13:08 resouer

@wonderflow Note that for non-core workload it still need revision labels to be automatically patched (not propagation).

Then let's automatically patch those labels including component.oam.dev/name. Users will be happy with less inputs.

zzxwill avatar Aug 27 '20 02:08 zzxwill

@zzxwill I agree. OAM Runtime should always patch exactly same label to PodTemplate as long as it exist.

That's also why I proposed a characteristic named podspecable in https://github.com/oam-dev/spec/issues/392 to WorkloadDefinition.

resouer avatar Aug 31 '20 23:08 resouer