-
Notifications
You must be signed in to change notification settings - Fork 267
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
Refactor make deploy to use apply instead of create #793
base: main
Are you sure you want to change the base?
Conversation
Signed-off-by: Varun Gupta <[email protected]>
Signed-off-by: Varun Gupta <[email protected]>
Signed-off-by: Varun Gupta <[email protected]>
Signed-off-by: Varun Gupta <[email protected]>
Signed-off-by: Varun Gupta <[email protected]>
@@ -4,9 +4,6 @@ kind: Kustomization | |||
# The workaround is to use kustomize namespace override to create under aibrix-system namespace. | |||
|
|||
resources: | |||
- crds/ray.io_rayclusters.yaml |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this redundant?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We have two make commands, make install and make deploy
. Both commands use kubectl create because of apply does not work if the CRD manifest is more than 261244 bytes. Currently, ray CRDs are installed as part of make deploy
, with this change ray CRDs will be installed as part of make install using kubectl create
and we can use kubectl apply in make deploy
.
Users need to run make install once and using kubectl create is OK. But make deploy need to be run with every version change or config change, so using kubectl apply is necessary for make deploy.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
em. this is a legacy issue. kuberay now are consider as an external package. it's not something like envoy gateway deployed in different namespace, it is deployed in aibrix namespace whose lifecycle is same as other aibrix components. that's the reason it deployed with other components in deploy
phase. separating CRD and other manifest is good practice but only this one seems unnecessary. If you think this affect apply
, I'd rather generate a crd version with shorter length instead but keep the lifecycle exact same.
@@ -227,15 +227,15 @@ endif | |||
.PHONY: install | |||
install: manifests kustomize ## Install CRDs into the K8s cluster specified in ~/.kube/config. | |||
## helm creates objects without aibrix prefix, hence deploying gateway components outside of kustomization | |||
$(KUBECTL) create -k config/dependency | |||
$(KUBECTL) apply -k config/dependency --server-side |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
EG parts looks good to me, we need to use apply --server-side for installing CRDs
Pull Request Description
Right now
make deploy
command useskubectl create
because ray related CRDs size is pretty big to supportkubectl apply
.Since envoy proxy CRD is also pretty big and requires
make create
, merging ray CRD with envoyproxy crd for installation such thatmake deploy can use kubectl apply
.Related Issues
Resolves: #[Insert issue number(s)]
Important: Before submitting, please complete the description above and review the checklist below.
Contribution Guidelines (Expand for Details)
We appreciate your contribution to aibrix! To ensure a smooth review process and maintain high code quality, please adhere to the following guidelines:
Pull Request Title Format
Your PR title should start with one of these prefixes to indicate the nature of the change:
[Bug]
: Corrections to existing functionality[CI]
: Changes to build process or CI pipeline[Docs]
: Updates or additions to documentation[API]
: Modifications to aibrix's API or interface[CLI]
: Changes or additions to the Command Line Interface[Misc]
: For changes not covered above (use sparingly)Note: For changes spanning multiple categories, use multiple prefixes in order of importance.
Submission Checklist
By submitting this PR, you confirm that you've read these guidelines and your changes align with the project's contribution standards.