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

Fixing false warnings for the KudoOperatorTask #1718

Merged
merged 1 commit into from
Oct 16, 2020

Conversation

zen-dog
Copy link
Contributor

@zen-dog zen-dog commented Oct 15, 2020

Summary:
in many cases, the task's OperatorVersion is being set by the dependency resolver during the package installation, so that it is valid for the field to be empty during verification.

Signed-off-by: Aleksey Dukhovniy alex.dukhovniy@googlemail.com

Summary:
in many cases the task's `OperatorVersion` is being set by the dependency resolver during the package installation so that it is valid for the field to be empty during verification.

Signed-off-by: Aleksey Dukhovniy <alex.dukhovniy@googlemail.com>
Copy link
Member

@nfnt nfnt left a comment

Choose a reason for hiding this comment

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

LGTM, but I don't quite understand the summary. It's saying that this is being set by the dependency resolver so it's valid to be empty during verification, but we are adding an error here when it's empty? Or am I missing something? What does this have to do with false warnings if this is setting an error?

Copy link
Member

@ANeumann82 ANeumann82 left a comment

Choose a reason for hiding this comment

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

lgtm

@ANeumann82
Copy link
Member

LGTM, but I don't quite understand the summary. It's saying that this is being set by the dependency resolver so it's valid to be empty during verification, but we are adding an error here when it's empty? Or am I missing something? What does this have to do with false warnings if this is setting an error?

Yeah, took me a minute to understand it as well - Basically, the PR removes one of the checks that is one in Task.build, which is ok, because when the Operator is installed it does the lookup on installation.

So the in_cluster_resolver on the client (CLI) is ok with an unset OV, as it searches through the repository to find one.
The in_cluster_resolver on the server (controller) is not ok with an unset OV, as it only tries to fetch an installed one.

I think I would prefer to have the in_cluster_resolver for the server to be adjusted, but this is ok for now...

@zen-dog
Copy link
Contributor Author

zen-dog commented Oct 16, 2020

I think I would prefer to have the in_cluster_resolver for the server to be adjusted, but this is ok for now...

The idea behind the server in_cluster_resolver is to only check the existing dependencies in case e.g. somebody created the OV/I manually and forgot the dependencies. So it is basically a sanity check:

  • all the resources should be installed
  • it doesn't really resolve as there should be no ambiguity about which OV to take. An actual resolver would then have to download and install the packages and that's something we don't want to do on the server.

maybe we should rename it to smth. like in_cluster_dependency_checker to avoid this confusion. wdyt @ANeumann82 ?

@zen-dog zen-dog merged commit 113db86 into main Oct 16, 2020
@zen-dog zen-dog deleted the ad/fix-kudooperatortask-verifier branch October 16, 2020 10:54
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants