Bug 1801736

Using a URL like `tensorflow/tensorflow:latest-jupyter` should work as is. However as a work-around you can try `docker.io/tensorflow/tensorflow:latest-jupyter`.

No luck with the URL you provided. I got the same error messages.


[root@worker01 ~]# oc get pods -n przemek
NAME                         READY   STATUS             RESTARTS   AGE
tensorflow-cb48f6c67-dgmqp   0/1     InvalidImageName   0          54s


[root@worker01 ~]# oc logs tensorflow-cb48f6c67-dgmqp -n przemek
Error from server (BadRequest): container "tensorflow" in pod "tensorflow-cb48f6c67-dgmqp" is waiting to start: InvalidImageName


[root@worker01 ~]# oc describe pod tensorflow-cb48f6c67-dgmqp -n przemek
Name:         tensorflow-cb48f6c67-dgmqp
Namespace:    przemek
Priority:     0
Node:         worker02.ocp4.scale.com/192.168.1.16
Start Time:   Tue, 11 Feb 2020 17:21:06 +0100
Labels:       app=tensorflow
              deploymentconfig=tensorflow
              pod-template-hash=cb48f6c67
Annotations:  k8s.v1.cni.cncf.io/networks-status:
                [{
                    "name": "openshift-sdn",
                    "interface": "eth0",
                    "ips": [
                        "10.128.2.69"
                    ],
                    "dns": {},
                    "default-route": [
                        "10.128.2.1"
                    ]
                }]
              openshift.io/generated-by: OpenShiftWebConsole
              openshift.io/scc: restricted
Status:       Pending
IP:           10.128.2.69
IPs:
  IP:           10.128.2.69
Controlled By:  ReplicaSet/tensorflow-cb48f6c67
Containers:
  tensorflow:
    Container ID:   
    Image:          tensorflow:
    Image ID:       
    Port:           8888/TCP
    Host Port:      0/TCP
    State:          Waiting
      Reason:       InvalidImageName
    Ready:          False
    Restart Count:  0
    Environment:    <none>
    Mounts:
      /var/run/secrets/kubernetes.io/serviceaccount from default-token-nz6m4 (ro)
Conditions:
  Type              Status
  Initialized       True 
  Ready             False 
  ContainersReady   False 
  PodScheduled      True 
Volumes:
  default-token-nz6m4:
    Type:        Secret (a volume populated by a Secret)
    SecretName:  default-token-nz6m4
    Optional:    false
QoS Class:       BestEffort
Node-Selectors:  <none>
Tolerations:     node.kubernetes.io/not-ready:NoExecute for 300s
                 node.kubernetes.io/unreachable:NoExecute for 300s
Events:
  Type     Reason         Age                From                              Message
  ----     ------         ----               ----                              -------
  Normal   Scheduled      <unknown>          default-scheduler                 Successfully assigned przemek/tensorflow-cb48f6c67-dgmqp to worker02.ocp4.scale.com
  Warning  InspectFailed  14s (x7 over 69s)  kubelet, worker02.ocp4.scale.com  Failed to apply default image tag "tensorflow:": couldn't parse image reference "tensorflow:": invalid reference format
  Warning  Failed         14s (x7 over 69s)  kubelet, worker02.ocp4.scale.com  Error: InvalidImageName

It's interesting to see the deploymentconfig, what does `oc get dc tensorflow -o yaml` print?

Tested in 4.4 as well and observed the same failure.

Tag is incorrectly set when choosing to create Deployments.

It works when creating a Deployment Config.

Fails again when creating a Knative service: `"image-registry.openshift-image-registry.svc:5000/cvogt/tensorflow-kn:latest-jupyter": failed to resolve image to digest: failed to fetch image information: MANIFEST_UNKNOWN: manifest unknown; map[Tag:latest-jupyter].`

Why is this marked as a test blocker?

I would like to test specific workloads with docker images. These are blocked as for now with deployments.

Verified on ci build: 4.4.0-0.ci-2020-02-18-102514
Chrome browser: 76.0.3809.132

Created attachment 1663900 [details]
Using Docker images for Applications is possible in Openshift 4.4.0

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2020:0581

The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days