Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Failed to parse image ${inputs.params.DOCKER_IMAGE}: could not parse reference #885

Closed
cmoulliard opened this issue May 21, 2019 · 6 comments

Comments

@cmoulliard
Copy link

cmoulliard commented May 21, 2019

Error

The following task when processed generates this error

Message:               
References a Task kube-system/s2i-jdk8 that doesn't exist:  couldn't create redirected TaskSpec: 
failed to add entrypoint to steps of TaskRun s2i-springboot-example: Failed to fetch remote image
${inputs.params.DOCKER_IMAGE}: Failed to parse image ${inputs.params.DOCKER_IMAGE}: could not 
parse reference

Config

apiVersion: tekton.dev/v1alpha1
kind: Task
metadata:
  name: s2i-jdk8
spec:
  inputs:
    params:
      - name: GIT_URL
        default: https://github.com/snowdrop/rest-http-example
      - name: BUILDER_IMAGE
        description: The location of the builder image.
        default: docker.io/kbaig/s2i
      - name: S2I_IMAGE
        description: The location of the s2i builder image.
        default: registry.access.redhat.com/redhat-openjdk-18/openjdk18-openshift
      - name: BUILDAH_IMAGE
        description: The location of the s2i builder image.
        default: quay.io/openshift-pipeline/buildah
      - name: DOCKER_IMAGE
        description: The location of the docker client image.
        default: gcr.io/cloud-builders/docker
      - name: TLSVERIFY
        description: Verify the TLS on the registry endpoint (for push/pull to a non-TLS registry)
        default: "true"
      - name: BUILD_IMAGE
        default: quay.io/snowdrop/spring-boot-example
  steps:
    - name: s2ibuild
      image: ${inputs.params.BUILDER_IMAGE}
      command:
      - s2i
      args:
      - build
      - ${inputs.params.GIT_URL}
      - ${inputs.params.S2I_IMAGE}
      - ${inputs.params.BUILD_IMAGE}
      volumeMounts:
      - name: docker-sock-volume
        mountPath: /var/run/docker.sock
      securityContext:
        privileged: true

    - name: docker-push
      image: ${inputs.params.DOCKER_IMAGE}
      args:
      - push
      - ${inputs.params.BUILD_IMAGE}
      volumeMounts:
      - name: docker-sock-volume
        mountPath: /var/run/docker.sock

  volumes:
    - name: docker-sock-volume
      hostPath:
        path: /var/run/docker.sock
@gavinfish
Copy link
Contributor

Similar with #811.

@bobcatfish
Copy link
Collaborator

Like @gavinfish said, I think what's happening here is that we aren't applying the templating to all fields, and as discussed in #811 we might as well :D

I'm going to close this in favor of #811. (Please re-open if we missed something @cmoulliard !)

@cmoulliard
Copy link
Author

A few remarks:

  • If the templating is working as described under When using ${variable} in containerTemplate, it is not working #811, why the error is only reported for the step docker-push and not for s2build as they both have a field defined as such image: ${inputs.params.BUILDER_IMAGE} and ${inputs.params.DOCKER_IMAGE} ?
  • Is it possible to report a more human readable message as this one don't at all explain that we have a templating issue References a Task kube-system/s2i-jdk8 that doesn't exist: couldn't create redirected TaskSpec: failed to add entrypoint to steps of TaskRun s2i-springboot-example: Failed to fetch remote image ${inputs.params.DOCKER_IMAGE}: Failed to parse image ${inputs.params.DOCKER_IMAGE}: could not parse reference ?

@bobcatfish
Copy link
Collaborator

If the templating is working as described under #811, why the error is only reported for the step docker-push and not for s2build as they both have a field defined as such image: ${inputs.params.BUILDER_IMAGE} and ${inputs.params.DOCKER_IMAGE} ?

It took me a few minutes to figure this out but the reason is actually pretty disappointing XD

This specific error ("Failed to fetch remote image") is caused by an implementation detail: we override the 'entrypoint'/'cmd' provided in the step with our own image (https://github.com/tektoncd/pipeline/blob/master/docs/developers/README.md#entrypoint-rewriting-and-step-ordering). When a step doesn't have a cmd defined, we have to fetch the image and look at it's metadata to see what the cmd actually is, so we can invoke it correctly. Since the first step s2ibuild has a cmd specified, we don't have to do that. If that had been the case for both steps, the problem you would have run into would have been that the resulting pod itself wouldn't be able to fetch the images.

🙏

References a Task kube-system/s2i-jdk8 that doesn't exist

That part is definitely wrong (@sbwsg I think this is that same code that you were fixing up in #876 (comment)).

failed to add entrypoint to steps of TaskRun s2i-springboot-example: Failed to fetch remote image ${inputs.params.DOCKER_IMAGE}: Failed to parse image ${inputs.params.DOCKER_IMAGE}: could not parse reference ?

So this is happening b/c this is the first bit of code that tries to interact with the value of image: which is why you're seeing the error at that point.

I think you're totally right though, we should catch that error earlier. The problem is that b/c we aren't applying any templating for those values, it's pretty hard to know that the user intended templating to work there and it didn't.

I guess we could find values that look like ${} and raise an error if they are being used where they shouldn't be? (If so maybe you can open a new issue specifically about that?)

      - name: BUILDAH_IMAGE
        description: The location of the s2i builder image.
        default: quay.io/openshift-pipeline/buildah
      - name: DOCKER_IMAGE
        description: The location of the docker client image.
        default: gcr.io/cloud-builders/docker

@cmoulliard can I ask a bit more about why you want to provide the images as params? Do you have a use case where you expect these to be swapped out? So far we have been assuming it would be find to hardcode image locations in Tasks ( + @dlorenc this might be relevant for Task entries in our catalog - maybe folks need to be able to swap out the images and/or the registry)

@cmoulliard
Copy link
Author

to provide the images as params?

This is because the URL of the image will change according to the registry where it will be published. when a local docker registry is available, then we will use the following by example URL service_name.namespace.svc.cluster.local:5000 but when it will be deployed on quay.io or docker.io, then we will another URL address

Make sense @bobcatfish ?

@bobcatfish
Copy link
Collaborator

Makes sense @cmoulliard - that's an interesting use case. I think for local registries / images we might want to have some other top level solution to this (related to #235 maybe).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants