Do Openshift Origin jobs need hard-coded internal

Question

I can't figure a namespace-portable way to build an image into an imagestream that can then be used for a job in an OpenShift project namespace without hard-coding the internal registry URL in the job config.

Unlike deployment configs, the job configuration does not automatically build a pod config with the image URL correct for the internal registry. The resulting job never runs because the image can't be pulled.

Failed to pull image "is-copy-adaptermappings": Error: image library/is-copy-adaptermappings:latest not found

Working example generated deployconfig-generated pod

...
 containers:
    - name: i2b2-webclient
      image: >-
        172.30.1.1:5000/c2/is-i2b2-webclient@sha256:51460a7b65ddd8cc32e41e9a3ac069efb587220364edc9285d06438b22e2ea47
      ports:
        - containerPort: 8080
          protocol: TCP
...

Failing example generated job pod excerpt

apiVersion: v1
kind: Pod
...
  containers:
    - name: copy-config-to-pv
      image: is-copy-adaptermappings
      resources: {}
      volumeMounts:
...

Job config (json)

{
  "apiVersion": "batch/v1",
  "kind": "Job",
  "metadata": {
    "name": "configpod"
  },
  "spec": {
    "parallelism": 1,
    "completions": 1,
    "template": {
      "metadata": {
        "name": "copy-config-to-pv"
      },
      "spec": {
        "containers": [
          {
            "name": "copy-config-to-pv",
            "image": "is-copy-adaptermappings",
            "imagePullPolicy": "Always",
            "volumeMounts": [
              {
                "mountPath": "/dest",
                "name": "volume-config"
              }
            ]
          }
        ],
        "restartPolicy": "OnFailure",
        "volumes": [
          {
            "name": "volume-config",
            "persistentVolumeClaim": {
              "claimName": "pvc-configs"
            }
          }
        ]
      }
    }
  }
}

Is there a good way of referring to, or generating that URL to the built-in local registry image?

Answer 1

As I understand it, it is this way because what you are using is actually the Kubernetes Job object. Anytime you do things at the Kubernetes level, you have to reference an image from an image registry. The concept of image streams doesn't exist in Kubernetes. This is where OpenShift objects such as build and deployment configuration are a bit smarter, as they work via the image stream object, which acts as a form of index or indirect pointer. The use of image streams as an intermediary makes things easier when using OpenShift.

That all said, I was told that there may be something in OpenShift 3.6 which does make this easier. Right now though, it apparently isn't documented as to how it works. The one person who can likely tell me about the details is on holiday to the end of the month, I am though seeing if I can find out more details and will update this when I know.

---

UPDATE 1

Provided you are using OpenShift 3.6, and is-copy-adaptermappings is an image stream in the current project, try the following:

{
  "apiVersion": "batch/v1",
  "kind": "Job",
  "metadata": {
    "name": "configpod"
    "annotations": {
      "alpha.image.policy.openshift.io/resolve-names": "*"
    },
  },
  "spec": {
    "parallelism": 1,
    "completions": 1,
    "template": {
      "metadata": {
        "name": "copy-config-to-pv"
      },
      "spec": {
        "containers": [
          {
            "name": "copy-config-to-pv",
            "image": "is-copy-adaptermappings",
            "imagePullPolicy": "Always",
            "volumeMounts": [
              {
                "mountPath": "/dest",
                "name": "volume-config"
              }
            ]
          }
        ],
        "restartPolicy": "OnFailure",
        "volumes": [
          {
            "name": "volume-config",
            "persistentVolumeClaim": {
              "claimName": "pvc-configs"
            }
          }
        ]
      }
    }
  }
}

The addition is the annotation with name alpha.image.policy.openshift.io/resolve-names in the metadata for the job.

The value of image can be imagestream name, in which case latest tag is used, or can be name:tag and reference a specific tag.

Using the annotation is this way has alpha status and as such the name of the annotation will eventually change. Usually they try and auto migrate names which incorporate alpha/beta tags, but do be aware that in case when status changes it stops working.

---

UPDATE 2

It looks like an alternate way to using the annotation that may now exist is to set is.spec.lookupPolicy and enable local lookup.

$ oc explain is.spec.lookupPolicy
RESOURCE: lookupPolicy <Object>

DESCRIPTION:
     lookupPolicy controls how other resources reference images within this
     namespace.

    ImageLookupPolicy describes how an image stream can be used to override the image references used by pods, builds, and other resources in a namespace.

FIELDS:
   local    <boolean> -required-
     local will change the docker short image references (like "mysql" or
     "php:latest") on objects in this namespace to the image ID whenever they
     match this image stream, instead of reaching out to a remote registry. The
     name will be fully qualified to an image ID if found. The tag's
     referencePolicy is taken into account on the replaced value. Only works
     within the current namespace.

That is, set this on the image stream object you want to reference in the image field.