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

Image-Che field not read correctly from deploy_che.sh (OpenShift) #14427

Closed
4 of 23 tasks
AmitChameides opened this issue Sep 5, 2019 · 6 comments
Closed
4 of 23 tasks
Labels
kind/question Questions that haven't been identified as being feature requests or bugs.

Comments

@AmitChameides
Copy link

Describe the bug

When certain values are put into the --image-che=(specified Che image) field when running the deploy_che.sh script, they are ignored or read incorrectly.

I had this happen when I was using a Che image from a local Docker registry. For the sake of this example, let's say the registry was 1.2.3.4:5000.
Then, my image repository would be 1.2.3.4:5000/my-image:my-image-tag. Changing the image to this tag or pushing/pulling from this tag works just fine.
However, when using the deploy_che.sh script (For example, by writing ./deploy_che.sh --multiuser --project=project-name --image-che=1.2.3.4:5000/my-image:my-image-tag), the image and the port are read incorrectly.
Instead of the source image being read as 1.2.3.4:5000/my-image and the image tag as my-image-tag, the source image is instead read as 1.2.3.4 and the image tag remains my-image-tag.
This, of course, makes Che unable to properly pull the image and results in an error when deploying the Che pod. Changing the environment variables of CHE_IMAGE_REPO and CHE_IMAGE_TAG has no effect as far as I've seen.

Che version

  • latest
  • nightly
  • other: please specify

Steps to reproduce

  1. Setup a local Docker registry.
  2. Pull an image of Eclipse/che-server from DockerHub to your local Docker instance.
  3. Change the tag of the pulled image to fit your local registry instead using the docker tag command.
  4. Push your newly-tagged image into the local registry using docker push.
  5. Create a new Che project using the command ./deploy_che.sh --multiuser --project=project-name --image-che=1.2.3.4:5000/my-image:my-image-tag.
  6. See immediately how the recognized image repository is incorrect.

Expected behavior

The image repository and tag read correctly from the input field of --image-che.

Runtime

  • kubernetes (include output of kubectl version)
  • Openshift (include output of oc version)
  • minikube (include output of minikube version and kubectl version)
  • minishift (include output of minishift version and oc version)
  • docker-desktop + K8S (include output of docker version and kubectl version)
  • other: (please specify)

Screenshots

Installation method

  • chectl
  • che-operator
  • minishift-addon
  • I don't know

Environment

  • my computer
    • Windows
    • Linux
    • macOS
  • Cloud
    • Amazon
    • Azure
    • GCE
    • other (please specify)
  • other: please specify

Additional context

I am aware that doing this requires authentication for the local Docker registry as well. I left it out of this bug report because it's irrelevant to it (The bug occurs prior to even trying to pull the image). But do note that I did set up a secret for the registry authentication, so the image pull fail isn't related to that.
Also, I'm running Che on OCP, and in multiuser mode.

@che-bot che-bot added the status/need-triage An issue that needs to be prioritized by the curator responsible for the triage. See https://github. label Sep 5, 2019
@tolusha tolusha added status/analyzing An issue has been proposed and it is currently being analyzed for effort and implementation approach and removed status/need-triage An issue that needs to be prioritized by the curator responsible for the triage. See https://github. labels Sep 5, 2019
@tolusha
Copy link
Contributor

tolusha commented Sep 5, 2019

@sleshchenko Could you check pls?

@skabashnyuk
Copy link
Contributor

@AmitChameides deploy.sh are in the decommissioning state #13888 can you test chectl https://www.eclipse.org/che/docs/che-7/installing-the-chectl-management-tool/?

@skabashnyuk skabashnyuk added kind/question Questions that haven't been identified as being feature requests or bugs. and removed status/analyzing An issue has been proposed and it is currently being analyzed for effort and implementation approach labels Sep 5, 2019
@che-bot che-bot added the status/need-triage An issue that needs to be prioritized by the curator responsible for the triage. See https://github. label Sep 5, 2019
@tolusha tolusha removed the status/need-triage An issue that needs to be prioritized by the curator responsible for the triage. See https://github. label Sep 5, 2019
@AmitChameides
Copy link
Author

Hey @skabashnyuk and @tolusha , thank you for your reply.
As I mentioned in this thread, I am currently running into bugs when trying to deploy using CheCtl. If you could assist me with making it work, I would greatly appreciate it.

@sleshchenko
Copy link
Member

@AmitChameides You're right, and deploy_che.sh does not expect registry to be specified in che-image argument. As a quick workaround I can suggest you try the following:

export CHE_IMAGE_REPO=1.2.3.4:5000/my-image
export CHE_IMAGE_TAG=my-image-tag
./deploy_che.sh --multiuser --project=project-name

@che-bot che-bot added the status/need-triage An issue that needs to be prioritized by the curator responsible for the triage. See https://github. label Sep 5, 2019
@AmitChameides
Copy link
Author

Thanks for your help @sleshchenko. That workaround indeed let me configure the correct local registry.
I'm still facing some small issues with the authentication part, but I'll try and tackle it a little myself, and in any case it's not related to this issue :)

@sleshchenko
Copy link
Member

@AmitChameides BTW if chectl does not allow to specify registry - please create the corresponding issue

@tolusha tolusha added team/platform and removed status/need-triage An issue that needs to be prioritized by the curator responsible for the triage. See https://github. labels Sep 5, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/question Questions that haven't been identified as being feature requests or bugs.
Projects
None yet
Development

No branches or pull requests

5 participants