Why are init-containers twice for DC ipaas-rest ?

[rhuss]

Snippet from the DC:

  template:
      metadata:
        labels:
          app: redhat-ipaas
          component: ipaas-rest
          deploymentconfig: ipaas-rest
        annotations:
          pod.beta.kubernetes.io/init-containers: |-
            [{
              "name": "openshift-ca-pemtokeystore",
              "image": "${PEMTOKEYSTORE_IMAGE}",
              "imagePullPolicy": "IfNotPresent",
              "args": [
                "-keystore", "/tls-keystore/openshift-truststore.jks",
                "-ca-file", "/var/run/secrets/kubernetes.io/serviceaccount/ca.crt",
                "-ca-file", "/var/run/secrets/kubernetes.io/serviceaccount/service-ca.crt",
                "-ca-dir", "/usr/share/ca-certificates/mozilla"
              ],
              "volumeMounts": [{
                "name": "ipaas-rest-tls",
                "mountPath": "/tls-keystore"
              }]
            }]
      spec:
        initContainers:
        - name: openshift-ca-pemtokeystore
          image: ${PEMTOKEYSTORE_IMAGE}
          imagePullPolicy: IfNotPresent
          args:
          - -keystore
          - /tls-keystore/openshift-truststore.jks
          - -ca-file
          - /var/run/secrets/kubernetes.io/serviceaccount/ca.crt
          - -ca-file
          - /var/run/secrets/kubernetes.io/serviceaccount/service-ca.crt
          - -ca-dir
          - /usr/share/ca-certificates/mozilla
          volumeMounts:
          - name: ipaas-rest-tls
            mountPath: /tls-keystore

Isn't it sufficient to add only one kind of init container (either as annotation or as within the spec) ? // @jimmidyson

[jimmidyson]

Future proofing :) In latest Kubernetes, it's properly part of spec, previous (and current OpenShift) requires annotations. Both do not conflict though luckily.

[rhuss]

Thanks ! Good to know that init containers come to spec. I always hated this json-in-yaml thing. At some point we should remove the annotation thing (when it lands in OpenShift, which probably will take a bit).

@jimmidyson General question : Is it generally so that unknown spec keys are ignored instead of raising an error ? so a bit like HTML ..

[jimmidyson]

Yeah I think so, although in this case it's not actually an unknown spec key, just one that has lower priority than the annotation key, depending on what version of kube is being used. The spec field has been there for a while, just unused in controllers, etc.