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

KEP-2170: Generate CRD manifests for v2 CustomResources #2237

Merged
merged 2 commits into from
Aug 30, 2024

Conversation

tenzen-y
Copy link
Member

@tenzen-y tenzen-y commented Aug 27, 2024

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:

- /
  - /manifests
    - /manifests/v2/base/crds 
    - /manifests/base             # for v1
    - /manifests/overlays       # for v1

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:

  • Docs included if any changes are user facing

@coveralls
Copy link

coveralls commented Aug 27, 2024

Pull Request Test Coverage Report for Build 10638979820

Details

  • 0 of 0 changed or added relevant lines in 0 files are covered.
  • 7 unchanged lines in 2 files lost coverage.
  • Overall coverage decreased (-0.06%) to 31.753%

Files with Coverage Reduction New Missed Lines %
pkg/controller.v1/mpi/mpijob.go 1 91.06%
pkg/controller.v1/mpi/mpijob_controller.go 6 80.67%
Totals Coverage Status
Change from base Build 10637686351: -0.06%
Covered Lines: 3944
Relevant Lines: 12421

💛 - Coveralls

@tenzen-y
Copy link
Member Author

/assign @kubeflow/wg-training-leads

@tenzen-y tenzen-y changed the title KEP-2170: Generate CRDs for v2 CRDs KEP-2170: Generate CRD manifests for v2 CRDs Aug 28, 2024
@tenzen-y tenzen-y changed the title KEP-2170: Generate CRD manifests for v2 CRDs KEP-2170: Generate CRD manifests for v2 CustomResources Aug 28, 2024
@tenzen-y
Copy link
Member Author

/hold

Makefile Outdated
@@ -38,9 +38,11 @@ help: ## Display this help.

manifests: controller-gen ## Generate WebhookConfiguration, ClusterRole and CustomResourceDefinition objects.
Copy link
Contributor

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.

Copy link
Member Author

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.

- name: Check manifests
run: |
make manifests && git add manifests &&
git diff --cached --exit-code || (echo 'Please run "make manifests" to generate manifests' && exit 1);

@andreyvelich
Copy link
Member

@tenzen-y What do you think about this structure ?

manifests/v1/base
manifests/v1/overlays
manifests/v2/base
manifests/v2/overlays

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 ?

Copy link
Member

@andreyvelich andreyvelich left a 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 @@
---
Copy link
Member

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

Copy link
Member Author

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.

Copy link
Member

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
Copy link
Member

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 ?

Copy link
Member Author

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.

@tenzen-y
Copy link
Member Author

@tenzen-y What do you think about this structure ?

manifests/v1/base
manifests/v1/overlays
manifests/v2/base
manifests/v2/overlays

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 ?

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.
But, I wouldn't modify the overlays directory in this PR.
I believe that we should work on entirely manifests creation and move user facing directory changes (overlays) so that users can easily observe the change of installation way.

@andreyvelich
Copy link
Member

I believe that we should work on entirely manifests creation and move user facing directory changes (overlays) so that users can easily observe the change of installation way.

In that case, how are going to support deployment/overlay of v1 and v2 version ?

@tenzen-y
Copy link
Member Author

I believe that we should work on entirely manifests creation and move user facing directory changes (overlays) so that users can easily observe the change of installation way.

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 meant we want to introduce the directory structure you proposed there: #2208

@tenzen-y
Copy link
Member Author

I renamed v2alpha1 with v2.

@@ -2,7 +2,7 @@ apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
namespace: kubeflow
resources:
- ../../base
- ../../base/v1
Copy link
Member

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 ?

Copy link
Member Author

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?

Copy link
Member

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 ?

Copy link
Member

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

Copy link
Member Author

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.

@tenzen-y tenzen-y force-pushed the geenrate-crds-v2 branch 3 times, most recently from f43bbce to 46bd6e5 Compare August 30, 2024 20:43
@tenzen-y
Copy link
Member Author

@andreyvelich I updated this PR, PTAL. Thanks.

Copy link
Member

@andreyvelich andreyvelich left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

/lgtm
/approve

@google-oss-prow google-oss-prow bot added the lgtm label Aug 30, 2024
Copy link

[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 /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@tenzen-y
Copy link
Member Author

/hold cancel

@google-oss-prow google-oss-prow bot merged commit 2455f7d into kubeflow:master Aug 30, 2024
39 checks passed
@tenzen-y tenzen-y deleted the geenrate-crds-v2 branch August 30, 2024 21:58
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants