Unable to change pod labels after injecting the openfeature pod

[mng1dev]

Hello,

I am trying to configure the operator for my deployment. However, part of my application logic also needs to set the value of a label of my pods on-the-fly, and this seems to be blocked on the pods where the flagd container is injected by the webhook.

The below bash script works fine in a deployment where the flagd container is not injected, and fails otherwise. Is this the expected behavior? If yes, is there any reason for preventing label changes on the pod?

API_SERVER_URL=https://kubernetes.default.svc
SERVICE_ACCOUNT_FOLDER=/var/run/secrets/kubernetes.io/serviceaccount
TOKEN=$(cat ${SERVICE_ACCOUNT_FOLDER}/token)
CACERT=${SERVICE_ACCOUNT_FOLDER}/ca.crt

curl \
--header "Content-Type: application/json-patch+json" \
--cacert ${CACERT} \
--header "Authorization: Bearer ${TOKEN}" \
-k \
--request PATCH \
--data '[{"op": "replace", "path": "/metadata/labels/mylabel", "value": "mylabelvalue"}]' \
${API_SERVER_URL}/api/v1/namespaces/mynamespace/pods/mypodname

[Kavindu-Dodan]

@mng1dev yes I can also see the same behavior when dealing with the operator. And I used kubectl label command instead of API access which is same [1]

k label pods/mypodname  foo=bar -n mynamespace

I found this[2] issue in K8s and when tried in my local setup I get the same error message. And k8s docs also confirm the same [3]

Pod updates may not change fields other than spec.containers[].image, spec.initContainers[].image, spec.activeDeadlineSeconds or spec.tolerations. For spec.tolerations, you can only add new entries.

I think what happens here is with OFO, there's an extra validation when mutating the pod through webhook which enforce the rules defined for the pod. So I think label update should be done at the deployment instead of the pod.

Let me know more details on your requirement so we can check more on this.

[1] - https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#updating-labels [2] - https://github.com/kubernetes/kubernetes/issues/121855 [3] - https://kubernetes.io/docs/concepts/workloads/pods/#pod-update-and-replacement