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

[Bug] Kuberay API Server Makefile target deploy-opeartor default image does not exist #1350

Open
2 tasks done
tedhtchang opened this issue Aug 18, 2023 · 2 comments
Open
2 tasks done
Assignees
Labels
apiserver bug Something isn't working P2 Important issue, but not time critical

Comments

@tedhtchang
Copy link
Contributor

tedhtchang commented Aug 18, 2023

Search before asking

  • I searched the issues and found no similar issues.

KubeRay Component

apiserver

What happened + What you expected to happen

The Makefile target deploy-operator deploys no-existing default image kuberay/operator:latest

Reproduction script

Run:

# clone the kuberay repo
cd apiserver
make deploy-operator
kubectl get pod

Got

NAME                                READY   STATUS         RESTARTS   AGE
kuberay-operator-664fc97c4c-tl5kl   0/1     ErrImagePull   0          100s

Expect:

NAME                                READY   STATUS    RESTARTS   AGE
kuberay-operator-6b864f7f7b-9crrp   1/1     Running   0          3m42s

Anything else

Recommend:
Change OPERATOR_IMAGE_TAG ?= nightly in the apiserver/Makefile and document how to specify version OPERATOR_IMAGE_TAG=v0.6.0 make deploy-operator in Development.md
Or
Tag latest or stable in the kuberay/operator repo

Are you willing to submit a PR?

  • Yes I am willing to submit a PR!
@tedhtchang tedhtchang added the bug Something isn't working label Aug 18, 2023
@tedhtchang
Copy link
Contributor Author

I realized the these deploy and deploy-operator commends need to follow other commends to work. For example:

# build image locally-> create KinD cluster -> load image to local KinD registry -> helm upgrade using the local registry
make docker-image cluster load-image deploy
make operator-image cluster load-operator-image deploy-operator

@z103cb Should we explicitly set helm to use KinD localhost registry in the makefile for the intention above ?

helm upgrade --install kuberay-apiserver ../helm-chart/kuberay-apiserver --wait --set image.tag=latest --set image.pullPolicy=IfNotPresent --set image.repository=localhost/kuberay/apiserver
helm upgrade --install raycluster ../helm-chart/kuberay-operator --wait --set image.tag=latest --set image.pullPolicy=IfNotPresent --set image.repository=localhost/kuberay/operator

@z103cb
Copy link
Contributor

z103cb commented Sep 14, 2023

I realized the these deploy and deploy-operator commends need to follow other commends to work. For example:

# build image locally-> create KinD cluster -> load image to local KinD registry -> helm upgrade using the local registry
make docker-image cluster load-image deploy
make operator-image cluster load-operator-image deploy-operator

@z103cb Should we explicitly set helm to use KinD localhost registry in the makefile for the intention above ?

helm upgrade --install kuberay-apiserver ../helm-chart/kuberay-apiserver --wait --set image.tag=latest --set image.pullPolicy=IfNotPresent --set image.repository=localhost/kuberay/apiserver
helm upgrade --install raycluster ../helm-chart/kuberay-operator --wait --set image.tag=latest --set image.pullPolicy=IfNotPresent --set image.repository=localhost/kuberay/operator

@tedhtchang perhaps not (the targets work for me without the need to set the registry). In retrospect, I think we should set the operator image to the nightly tag and document how to build and deploy an operator image from source (perhaps add the targets to make things simpler).

Thoughts ?

@kevin85421 kevin85421 added the P2 Important issue, but not time critical label Jan 30, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
apiserver bug Something isn't working P2 Important issue, but not time critical
Projects
None yet
Development

No branches or pull requests

3 participants