-
Notifications
You must be signed in to change notification settings - Fork 55
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
Create webhook for NIM enablement #288
Create webhook for NIM enablement #288
Conversation
Hi @xieshenzh. Thanks for your PR. I'm waiting for a opendatahub-io member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
09288d1
to
6a12973
Compare
Could you please write tests for this webhook? |
|
oh I missed it. thanks for the tests. I will review this. |
return field.Invalid(field.NewPath("spec").Child("apiKeySecret").Child("name"), newAccount.Spec.APIKeySecret.Name, msg) | ||
} | ||
name := newAccount.Spec.APIKeySecret.Name | ||
namespace := newAccount.Spec.APIKeySecret.Namespace |
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.
namespace can be different from where it is created?
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.
Technically, the namespace of the Secret can be different from the namespace of the Account.
If there is a requirement to disallow this scenario, this webhook should reject Account creation or update in this case.
But I have not received such requirement so far.
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.
odh-model-controller can access to all namespaces and also so can get secret but it is for internal usage for odh-model-controller
. But if it is available to access all secrets in the cluster by this cr, I think it is not a good idea for security reasons. @etirelli @terrytangyuan @israel-hdez 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.
@@ -116,7 +116,8 @@ var _ = BeforeSuite(func() { | |||
By("Bootstrapping test environment") | |||
envTest = &envtest.Environment{ | |||
CRDInstallOptions: envtest.CRDInstallOptions{ | |||
Paths: []string{filepath.Join("..", "config", "crd", "external")}, | |||
Paths: []string{filepath.Join("..", "config", "crd", "external"), | |||
filepath.Join("..", "config", "crd", "bases")}, |
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.
tbh, i would think this new CRD to be shipped out by kserve as an overlay not by odh-model-controller.
say, kserve is disabled, modelmesh is enabled, CRD would still be installed in the cluster, should it?
or not include "crd/bases" from "base/kustomization.yaml".
instead, in Operator to create it on kserve demand.
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.
@etirelli @israel-hdez @lburgazzoli @TomerFi @Jooho @mpaulgreen
Any thoughts on the suggestions?
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.
Here are some legacy comments that can drive the decision. Please feel free to override me. https://issues.redhat.com/projects/NVPE/issues/NVPE-4?filter=allissues and from a slack thread - https://redhat-internal.slack.com/archives/C07CZDA6DE1/p1730391034630149?thread_ts=1730389624.036899&cid=C07CZDA6DE1
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.
@zdtsw I believe this was discussed before, and the overall agreement was that odh-model-controller is the best choice at the moment. I think you are correct on the model-mesh case, but at the same time, I believe the idea is to eventually remove model-mesh, so it would be a non-issue. But I defer to the model serving team if they think otherwise.
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 do not have objection to place CRD in such a way
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.
No strong preference on this. I think it's fine keep it as is.
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'm OK with having the CRD in this repo.
90473a2
to
77f564c
Compare
@@ -116,7 +116,8 @@ var _ = BeforeSuite(func() { | |||
By("Bootstrapping test environment") | |||
envTest = &envtest.Environment{ | |||
CRDInstallOptions: envtest.CRDInstallOptions{ | |||
Paths: []string{filepath.Join("..", "config", "crd", "external")}, | |||
Paths: []string{filepath.Join("..", "config", "crd", "external"), | |||
filepath.Join("..", "config", "crd", "bases")}, |
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.
No strong preference on this. I think it's fine keep it as is.
Signed-off-by: Xieshen Zhang <[email protected]>
77f564c
to
8f8c62c
Compare
@Jooho I don't think there is any outstanding concerns on this PR. |
/ok-to-test |
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
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: israel-hdez, TomerFi, xieshenzh 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 |
Create the validation webhook for NIM Account.
Description
How Has This Been Tested?
2.1 Check if the Account is created when the api key secret is not created
2.2 Check if the Account is created when there is already an Account CR in the namespace
2.3 Check if the Account is created when the api key secret is created and there is no other Account in the namespace
3.1 Check if the Account is updated when updating the api key secret and the new api key secret is not created
3.2 Check if the Account is updated when updating the api key secret and the new api key secret is created
Merge criteria: