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

feat: webhook: Check if DataImportCronTemplate is correct #1162

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

akrejcir
Copy link
Collaborator

@akrejcir akrejcir commented Dec 5, 2024

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:

None

@kubevirt-bot kubevirt-bot added release-note-none Denotes a PR that doesn't merit a release note. dco-signoff: yes Indicates the PR's author has DCO signed all their commits. labels Dec 5, 2024
@kubevirt-bot
Copy link
Contributor

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please ask for approval from akrejcir. For more information see the Kubernetes Code Review Process.

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

@akrejcir
Copy link
Collaborator Author

akrejcir commented Dec 5, 2024

/cc @0xFelix @jcanocan @codingben

@codingben
Copy link
Member

The code is copied from CDI webhook. They don't export the code, so we cannot import it as a module.

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

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()

Copy link
Collaborator Author

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.

Copy link
Collaborator Author

@akrejcir akrejcir Dec 6, 2024

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.

Copy link
Member

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. :)

Copy link
Contributor

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?

Copy link
Collaborator Author

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.

webhooks/data-import-cron.go Outdated Show resolved Hide resolved
Comment on lines +185 to +186
sourceURL := sourceRegistry.URL
sourceIS := sourceRegistry.ImageStream
Copy link
Member

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

Copy link
Collaborator Author

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() {
Copy link
Member

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?

Copy link
Member

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?

Copy link
Collaborator Author

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.

Copy link
Collaborator Author

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?

webhooks/ssp_webhook.go Outdated Show resolved Hide resolved
@akrejcir akrejcir force-pushed the webhook-dict branch 2 times, most recently from f020458 to 0043522 Compare December 6, 2024 13:20
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]>
Copy link

sonarqubecloud bot commented Dec 6, 2024

@akalenyu
Copy link
Contributor

akalenyu commented Dec 8, 2024

The code is copied from CDI webhook. They don't export the code, so we cannot import it as a module.

Isn't exportable at all? What would be @akalenyu's opinion about this?

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,
when we could instead just propagate the creation error properly to the status. Would that not suffice?
Another option is dry running the creation.

@0xFelix
Copy link
Member

0xFelix commented Dec 9, 2024

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?

@akrejcir
Copy link
Collaborator Author

akrejcir commented Dec 9, 2024

My general thoughts are, with all the recent focus on webhooks, I am not sure we want to copy the webhook,
when we could instead just propagate the creation error properly to the status. Would that not suffice?
Another option is dry running the creation.

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.

@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?

It will not fail reconciliation, bacuase the invalid SSP object is rejected in webhook.

@akalenyu
Copy link
Contributor

akalenyu commented Dec 9, 2024

Rejecting an incorrect SSP in webhook would be faster

As a project we kind of decided that this is not enough of an advantage versus all the bad stuff webhooks bring.
I see no issue with solving the bug by reporting the error in the status (users should be checking that)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
dco-signoff: yes Indicates the PR's author has DCO signed all their commits. release-note-none Denotes a PR that doesn't merit a release note. size/XXL
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants