kudoinit refactoring

[ANeumann82]

Extracted refactoring of kudoinit from #1467
-- The Verify-Methods now don't return a verifier.Result anymore, but get a verifier.Result as a parameter and return a normal error to be more in sync with normal go error handling. The Verify methods can either return normally ( and have a result with errors/warnings that describe issues with the installation) or abnormally ( then they return an error) if the verification failed due to unexpected issues (api-server not responding, etc.)
-- The prerequisites (namespace, service account, webhooks, etc.) are now simple kudoinit.Steps and not special extra subtypes.

[nfnt]

This is great, thanks for adding a distinction between these different kinds of error sources. Looks like a lot of API errors were swallowed in the old code. Only have some minor regards.

[nfnt]

How about returning (verifier.Result, error) instead? This way there would be a clear distinction between input and output values. Also, currently most of the times when PreInstallVerify is called we have something like this:

result := verifier.NewResult()
err = crd.NewInitializer().VerifyInstallation(kubeClient, &result)

whereas

result, err := crd.NewInitializer().VerifyInstallation(kubeClient)

is much clearer IMO. For the code in crds.go to merges multiple Results, we could then use result.Merge. WDYT?

[ANeumann82]

Yeah... I'm not sure, to be honest. This was basically the pattern I had before, and I do agree it looks nicer on the caller side.

Passing the result in allow the handling inside the funcs to look like this though:

	if err := o.validateServiceAccountExists(client, result); err != nil {
		return err
	}

If were to return (verifier.Result, error) it would have to look like this:

    myRes := verifier.NewResult{}
    res, err := o.validateServiceAccountExists(client)
    if err != nil {
        return err
    }
    myRes.merge(res)
   
    // ... next check, validate SA permissions
    return res

So... It might be an option to change the signature for the Top-Level methods, but that is at the cost of consistency.

If other devs feels strongly about this as well I'll change it, but at the moment I prefer it like this.

[nfnt]

Yeah, I see how having multiple return values complicates things a bit, we can't do

result.Merge(o.validateServiceAccountExists(client))

I don't feel strongly about this, happy to keep it as it is right now.

[nfnt]

Hmm, the old code doesn't do that, but shouldn't we run VerifyInstallation only if validateInstall == true? Closely related: If we run VerifyInstallation regardless of validateInstall, we should always return its error if there is on, similar to how it's done in the old code.

[ANeumann82]

Well - generally we always want to run VerifyInstallation. The validateInstall parameter is by default "true", and it allows a user to continue with the process even if the verification is returning errors. It's basically "I know what I'm doing, don't annoy me"-Button.

For returning an error - The new code behaves the same as the old one, as far as I can see: It aborts if the verification fails and the parameter is true, and continues if the parameter is false.

I have renamed the parameter though...

[nfnt]

The old code returned an error only for os.IsTimeout, regardless of validateInstall. IMO, we should do the same and always return an error if VerifyInstallation returns one, because it indicates something wrong with the cluster in general. For warnings/errors related to the CRDs specifically, Result is used and there validateInstall decides if an error is reported. WDYT?

[ANeumann82]

Oooh, that's what you mean. Right. Yeah, that makes sense.

[nfnt]

LGTM, I don't have strong opinion on the comments raised above.

[zen-dog]

I like this 👍

[zen-dog]

Lgtm!