Uploaded image for project: 'OpenShift Service Mesh'
  1. OpenShift Service Mesh
  2. OSSM-1074

Pod annotations defined in SMCP are not injected in the pods

XMLWordPrintable

    • OSSM 2.2 - 2

      OSSM doesn't follow the same rules as OpenShift does to inject annotations into the pods. 

      One can define annotations for a container in a deployment like this:

       34   template:
       35     metadata:
       36       annotations:
       37         openshift.io/generated-by: OpenShiftNewApp
       38         sidecar.istio.io/inject: "true"
       39         test1.annotation-from-deployment: test1
       40         test2.annotation-from-deployment: '["test2"]'
       41         test3.annotation-from-deployment: test-3
       42         test4.annotation-from-deployment: test_4
       43         test5.annotation-from-deployment: '{test5}' 

       

      And the resulting pod will have the annotations set correctly:

       

       45     test1.annotation-from-deployment: test1
       46     test2.annotation-from-deployment: '["test2"]'
       47     test3.annotation-from-deployment: test-3
       48     test4.annotation-from-deployment: test_4
       49     test5.annotation-from-deployment: '{test5}'
       50     traffic.sidecar.istio.io/excludeInboundPorts: 15090,15021 

       

      When defining simple annotations in the injections section of the SMCP, it works as expected:

       30   proxy:
       31     accessLogging:
       32       file:
       33         name: /dev/stdout
       34     injection:
       35     injection:
       36       autoInject: true
       37       injectedAnnotations:
       38         test0.annotation-from-smcp: test0 

      And the pod gets the annotation from the SMCP as well as the annotation from the deployment:

       45     test0.annotation-from-smcp: test0
       46     test1.annotation-from-deployment: test1
       47     test2.annotation-from-deployment: '["test2"]'
       48     test3.annotation-from-deployment: test-3
       49     test4.annotation-from-deployment: test_4
       50     test5.annotation-from-deployment: '{test5}'
       51     traffic.sidecar.istio.io/excludeInboundPorts: 15090,15021 

      But when using annotations that include the symbols "[" , "]" , "{" , "}", the annotations are no longer injected in the pod: 

       34     injection:
       35       autoInject: true
       36       injectedAnnotations:
       37         test0.annotation-from-smcp: test0
       38         test1.annotation-from-smcp: test1
       39         test2.annotation-from-smcp: '["test2"]'
       40         test3.annotation-from-smcp: '{test3}' 

      These annotations seem to be ignored. Even if you add another valid annotations, if there's any non-valid character in one of the new annotations, all the new annotations in the SMCP are omitted:

       45     test0.annotation-from-smcp: test0
       46     test1.annotation-from-deployment: test1
       47     test1.annotation-from-smcp: test1
       48     test2.annotation-from-deployment: '["test2"]'
       49     test3.annotation-from-deployment: test-3
       50     test4.annotation-from-deployment: test_4
       51     test5.annotation-from-deployment: '{test5}'
       52     traffic.sidecar.istio.io/excludeInboundPorts: 15090,15021

      The istiod pod shows the following error:

       

      2022-02-15T13:19:34.799227Z     error   update error: failed to unmarshal injection template: error converting YAML to JSON: yaml: line 10: did not find expected key 

      That seems to come from here: https://github.com/maistra/istio/blob/5f8f4917ef775c5a8696fa9a096cab1a051f24dc/pkg/kube/inject/inject.go#L153

       

      Can we change the behaviour of the injections to match the way K8s/OpenShift behaving when adding annotations to the deployments?

              mluksa@redhat.com Marko Luksa
              rhn-support-asolanas Alexis Solanas
              Votes:
              0 Vote for this issue
              Watchers:
              7 Start watching this issue

                Created:
                Updated:
                Resolved: