-
Notifications
You must be signed in to change notification settings - Fork 715
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
KEP-2170: Generate CRD manifests for v2 CustomResources #2237
Conversation
Pull Request Test Coverage Report for Build 10638979820Details
💛 - Coveralls |
/assign @kubeflow/wg-training-leads |
e762c35
to
33f0d4b
Compare
/hold |
33f0d4b
to
efa6c8d
Compare
Makefile
Outdated
@@ -38,9 +38,11 @@ help: ## Display this help. | |||
|
|||
manifests: controller-gen ## Generate WebhookConfiguration, ClusterRole and CustomResourceDefinition objects. |
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.
This could be a followup but I have found it useful to have some check in the CI to make sure external contributors are not commiting an API change without generating the manifests.
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.
Indeed, we already checked in our CI.
training-operator/.github/workflows/test-go.yaml
Lines 32 to 35 in ea5272f
- name: Check manifests | |
run: | | |
make manifests && git add manifests && | |
git diff --cached --exit-code || (echo 'Please run "make manifests" to generate manifests' && exit 1); |
@tenzen-y What do you think about this structure ?
Similar to Katib: https://github.com/kubeflow/katib/tree/master/manifests/v1beta1 ? Also, are we planning to maintain and deploy both CRDs for v2alpha1 and v2beta1 in the future ? |
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.
Thanks for this @tenzen-y!
/assign @kubeflow/wg-training-leads @shravan-achar
@@ -0,0 +1,9275 @@ | |||
--- |
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.
I am wondering are what are advantages for the CEL validation if we have validation webhook ?
I noticed that if CRD becomes to large it can cause issues. For example: kserve/kserve#3487
cc @terrytangyuan @kubeflow/wg-training-leads
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.
That's not a problem. We can avoid the problem with --server-side
option.
We should introduce the CEL validation to reduce Kube-API server loads.
In the big cluster, many webhook validations are a big deal for performance issues. Specifically, kube-apiserver and etcd are so busy in batch clusters with hundreds and thousands of Jobs.
For UX, CEL validation could be reduce kubectl / SDK response time since the kube-apiserver does not need to call external webhook servers, the kubeapi-server could just evaluate incoming Job objects inside of kube-apiserver.
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.
Make sense! Let's see if our CRD can go too-large even with server side option.
@@ -23,6 +23,8 @@ import ( | |||
) | |||
|
|||
// +kubebuilder:object:root=true | |||
// +kubebuilder:storageversion |
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.
Do we need storageversion for CRD version migrations in the future ?
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.
Yes, I guess that we need this storageVersion for the situation where we switched to v2apha2 or v2beta1.
I don't think that we should support both v2alpha1 and other v2 versions. So, let's rename v2alpha1 with v2. For the directory structure, The directory structure looks good to me. |
In that case, how are going to support deployment/overlay of v1 and v2 version ? |
Sorry, I accidentally sent the message on the way... |
I renamed v2alpha1 with v2. |
@@ -2,7 +2,7 @@ apiVersion: kustomize.config.k8s.io/v1beta1 | |||
kind: Kustomization | |||
namespace: kubeflow | |||
resources: | |||
- ../../base | |||
- ../../base/v1 |
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.
@tenzen-y So why you don't want to separate overlays between v1 and v2 version ?
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.
I want to prepare /manifests/v2
and /manifests/v1
when we create manifests for v2.
Because we want to mitigate the impact for the existing v1 users who use the master branch.
In that case, in this PR, we may want to just add the /manifests/v2
directory, and then we can keep the existing v1 manifests directory until we introduce the v2 manifests. WDYT?
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.
I see, that makes sense, since it will break any users' GitOps/CD that might be configured on the master branch for Training Operator installation.
In that case, are we planning to introduce /manifests/overlays/v2
in the future ?
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.
If you want we can move base + overlays to the v2 folder all together and don't touch v1 at all:
/manifests/v2/base/crds
/manifests/v2/base/controller
/manifests/v2/overlays/standalone
/manifests/v2/overlays/kubeflow
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.
If you want we can move base + overlays to the v2 folder all together and don't touch v1 at all:
/manifests/v2/base/crds /manifests/v2/base/controller /manifests/v2/overlays/standalone /manifests/v2/overlays/kubeflow
Yes, I want to select the approach. Let's align this PR with the directory structure.
f43bbce
to
46bd6e5
Compare
Signed-off-by: Yuki Iwai <[email protected]>
Signed-off-by: Yuki Iwai <[email protected]>
46bd6e5
to
a5d1ed0
Compare
@andreyvelich I updated this PR, PTAL. Thanks. |
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.
/lgtm
/approve
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: andreyvelich, shravan-achar The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
/hold cancel |
What this PR does / why we need it:
I generated CRD manifests for v2 CustomResources because we need CRD manifests in the first implementation PR: #2236.
Since this PR, the manifests directory looks like the following:
Additionally, I added some kubebuilder markers to generate CRDs.
Which issue(s) this PR fixes (optional, in
Fixes #<issue number>, #<issue number>, ...
format, will close the issue(s) when PR gets merged):Part-of: #2208
Checklist: