-
Notifications
You must be signed in to change notification settings - Fork 47
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
feat: webhook: Check if DataImportCronTemplate is correct #1162
base: main
Are you sure you want to change the base?
Conversation
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
709ee48
to
c8ede89
Compare
Isn't exportable at all? What would be @akalenyu's opinion about this? |
func validateNumberOfSources(source *cdiv1beta1.DataVolumeSource) error { | ||
numberOfSources := 0 | ||
s := reflect.ValueOf(source).Elem() | ||
for i := 0; i < s.NumField(); i++ { |
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.
nit: Use for i := range s.NumField()
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.
Done.
TIL that range
can have int
argument. I assumed only slices and maps can be there.
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.
But golangci-lint
complains about it:
golangci/golangci-lint info installed /workspace/bin/golangci-lint
/workspace/bin/golangci-lint run --timeout 5m
webhooks/data-import-cron.go:170:17: cannot range over s.NumField() (value of type int) (typecheck)
for i := range s.NumField() {
^
make: *** [Makefile:327: lint] Error 1
Even if it compiles and works: https://go.dev/play/p/KbogyWbaifX?v=goprev
Maybe we need to update the linter. For now, I will revert it.
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.
IIRC that was introduced with golang 1.22. :)
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.
Maybe the problem is that the linter is already a bit old. IIRC, we are using golangci-lint
1.55.2, which is based in golang 1.21.3. Could you please try to update the golangci-lint
version up to 1.62.2 and try again?
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 will do it in a separate PR.
sourceURL := sourceRegistry.URL | ||
sourceIS := sourceRegistry.ImageStream |
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.
Up to you but I'd inline most of these vars
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'd keep them this way. It would be too verbose if inlined.
Expect(err).To(MatchError(ContainSubstring("unsupported value:"))) | ||
}) | ||
|
||
It("should fail if there are multiple access modes in PVC", func() { |
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 case is missing for Storage?
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.
Can the cases not be split e.g. like other ones?
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.
It is allowed to have multiple access modes for Storage
. At least the CDI webhook allows it.
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.
Can the cases not be split e.g. like other ones?
What do you mean?
f020458
to
0043522
Compare
Added webhook code to check if DataImportCronTemplate is correct. The code is copied from CDI webhook. They don't export the code, so we cannot import it as a module. Signed-off-by: Andrej Krejcir <[email protected]>
Added unit tests for DataImportCronTemplate check in the webhook. Signed-off-by: Andrej Krejcir <[email protected]>
0043522
to
f3255a2
Compare
Quality Gate passedIssues Measures |
Yeah I don't think there is a good reason to export it. We did export the authorization bits at one point kubevirt/containerized-data-importer#2636 but that is a must for any project that embeds DataVolumes for security reasons. My general thoughts are, with all the recent focus on webhooks, I am not sure we want to copy the webhook, |
I like the idea of using the dry running option. @akrejcir Can you explain how having these checks in SSP fixes the initial issue? Won't it still fail its reconciliation because the supplied DIC templates are not valid? |
Ok, I will look into propagating the error into status. Rejecting an incorrect SSP in webhook would be faster, but we need a lot of copied code. I didn't want to call dry-run create API in the webhook, because the webhook should be fast, and there is a set timeout for it. There can be any number of DataImportCronTemplates specified in the SSP, and doing many API calls in the webhook could take too long.
It will not fail reconciliation, bacuase the invalid SSP object is rejected in webhook. |
As a project we kind of decided that this is not enough of an advantage versus all the bad stuff webhooks bring. |
What this PR does / why we need it:
Added webhook code to check if DataImportCronTemplate is correct.
The code is copied from CDI webhook. They don't export the code, so we cannot import it as a module.
Which issue(s) this PR fixes:
Fixes: https://issues.redhat.com/browse/CNV-48792
Release note: