propagate labels to deployments and pods

[lburgazzoli]

I've configured a KameletBinding to propagate some labels to generated resources, ad that work till the Integration:

➜ k get KameletBinding/c6911f7b28b7443f090b779dfcc404a90 --show-labels 
acme.com/my-label.generated=true,acme.com/my-label.id=1uPZZ2GK5dNNY87It5oa3AwEOxE,acme.com/my-label.operator=camel-k,acme.com/my-label.type.id=log

➜ k get Integration/c6911f7b28b7443f090b779dfcc404a90 --show-labels 
acme.com/my-label.generated=true,acme.com/my-label.id=1uPZZ2GK5dNNY87It5oa3AwEOxE,acme.com/my-label.operator=camel-k,acme.com/my-label.type.id=log

Those labels are then not propagated down to the POD:

➜ k get Pod/c6911f7b28b7443f090b779dfcc404a90-844d994877-vcxgn --show-labels 
camel.apache.org/integration=c6911f7b28b7443f090b779dfcc404a90,pod-template-hash=844d994877

it would be nice to get such labels propagated to each direct or indirect generated resource

[lburgazzoli]

/cc @astefanutti @nicolaferraro

[nicolaferraro]

I think there's a trait to control that: owner.target-labels...
May we change the default to transfer them all?

[lburgazzoli]

This stops at the Integration level, pods and deployment does not have such labels propagated (unless I missed something)

[squakez]

The correct way to have it working with the actual owner trait is the following one:

apiVersion: camel.apache.org/v1alpha1
kind: KameletBinding
...
metadata:
...
  labels:
    my-key: my-val
    ...
  annotations:
    trait.camel.apache.org/owner.target-labels: "my-key"

k get pod --show-labels -n operator-test
NAME                            READY   STATUS    RESTARTS   AGE   LABELS
timer-to-log-686fc7f567-gfhb6   1/1     Running   0          8s    camel.apache.org/integration=timer-to-log,my-key=my-val,pod-template-hash=686fc7f567

Basically we need to specify in the KameletBinding which labels (and/or annotations) we want to have in the underlying Pod.

In the KameletBinding usage, I think it's a bit cumbersome as we need to re-declare a list of variables we already defined. In my opinion we should add a owner.target-labels-all to cover the generic usage of including all labels/annotations. We can also consider if the default for the KameletBinding is to use the owner trait, so the user won't have to bother to configure (he can disable by turning enabled=false).

[lburgazzoli]

The correct way to have it working with the actual owner trait is the following one:

apiVersion: camel.apache.org/v1alpha1
kind: KameletBinding
...
metadata:
...
  labels:
    my-key: my-val
    ...
  annotations:
    trait.camel.apache.org/owner.target-labels: "my-key"

k get pod --show-labels -n operator-test
NAME                            READY   STATUS    RESTARTS   AGE   LABELS
timer-to-log-686fc7f567-gfhb6   1/1     Running   0          8s    camel.apache.org/integration=timer-to-log,my-key=my-val,pod-template-hash=686fc7f567

Basically we need to specify in the KameletBinding which labels (and/or annotations) we want to have in the underlying Pod.

This is what I did in my set-up but was based on an 1.4 version so it may have been solved, need to re-test.

In the KameletBinding usage, I think it's a bit cumbersome as we need to re-declare a list of variables we already defined. In my opinion we should add a owner.target-labels-all to cover the generic usage of including all labels/annotations. We can also consider if the default for the KameletBinding is to use the owner trait, so the user won't have to bother to configure (he can disable by turning enabled=false).

copying all the labels/annotations by default is a little bit risky imho, may be nice to have some support for regexp

[squakez]

Yes, I've tested with 1.5, so probably it was a bug in 1.4. Let me know if upgrading version fixes for you as well.

[squakez]

I managed to reproduce in 1.5 as well. Likely the problem is because of the syntax expected by the array values. It expects to be like trait.camel.apache.org/owner.target-labels: "[\"my-key.1\", \"my-key.2\"]". I'm adding a note to have it correctly documented, in the while, please @lburgazzoli confirm if that fixes the problem.

[lburgazzoli]

@squakez yes, using "array" seems to work