Refactor into stateful types and remove viper dependency from pkg/ code

[xrstf]

This started out as a simple "remove the viper.WriteConfig line" PR and then slowly escalated over the last few hours.

My main goal here was to fix #175 and my idea was to introduce a Configuration struct that we can pass into othe components, instead of making the entire codebase rely on global state and viper.String() calls.

However, mapping pflags via viper to a config file makes it, as far as I could see, impossible to keep the Configuration struct I was aiming for. When using viper, the whole "load the config file, merge it with CLI flags" logic is based around the idea that you then use viper.Get... to retrieve the merged data. Viper will not (AFAIK) write the merged data back into the struct.

So instead of using Viper to map the flags, I hand rolled a bit of code to load a YAML file and merge the flags with it. As discussed in #175, the logic is:

• if something is explicitly given via CLI flag, that has priority.
• if not, if a config file was given explicitly via --config, it is loaded and the value in the config file is used if not empty.
• if there is no config file or the value in the config file is empty, then the hydrophone default value is used.

The config file is never written to by hydrophone. Users have to manually create one if they want to use it.

Importantly, the 3 different run modes (cleanup, list-images, conformance[/--focus]) are not part of the Configuration, as they only serve a purpose in the root command to distinguish which code to call. Personally I would even remove Verbosity, DryRun and Parallel from the config file, but it doesn't hurt to have them there either.

---

Once the config was turned into a struct, I proceeded to get rid of some init() functions to reduce overall global state. What previously were global static functions like service.Cleanup are now functions on a TestRunner struct, which holds the necessary dependencies (and, importantly, gets the Configuration injected).

The service package was renamed to conformance, as the package implements running the Kubernetes conformance suite. The client to access the results was moved to pkg/conformance/client.

Lots of code from the common package was moved into a new types package, type-ical for Kubernetes projects. 😁

The recently introduced ImagePullBackoff check was moved into a CreatePod() helper function that now simply waits for the Pod to be running before continuing.

---

One thing lead to another and now half the codebase was moved around 😬

[xrstf]

/kind cleanup

[rakshitgondwal]

Thanks for this, it is going to take a little while to review this whole, but even I was thinking what could be the best way to fix the issue with viper.
One thing I thought about was to just use WriteConfig() instead of SafeWriteConfig() which would lead to an overwrite of config file everytime. But then another thing came up that do we actually need Viper? why don't we just make the flag variables as global and reference them across, not sure if this would be a tidy method though.

But still I'll have a look at your approach :)

[xrstf]

why don't we just make the flag variables as global and reference them across

Global variables make it extremely hard to understand data flow and make it uneccessarily complicated to re-use / test code. Calling viper.String() everywhere is just as bad as having a global variable. Hydrophone's code was already sprinkled with init() functions that made it complicated to follow what's going on. I don't think adding even more global state would help the codebase.

One thing I thought about was to just use WriteConfig() instead of SafeWriteConfig() which would lead to an overwrite of config file everytime.

And what is the point then to overwrite the config file everytime? In what scenario would that be desirable? If I don't specify a --config flag, I do not want to use a config file. If I do specify the --config flag, then please do not fiddle with it and overwrite it. :D I might have mounted it from a ConfigMap or run in a read-only filesystem.

Even if you overwrite the config file every single time, you are still remembering the last settings/flags and re-using them for the next run of hydrophone. So we would still diverge from what is shown as default in --help and what is actually the "default".

[rjsadow]

/lgtm
/approve

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: rjsadow, xrstf

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:

• OWNERS [rjsadow]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment