Add support for Subscription.config.affinity

[perdasilva]

Signed-off-by: perdasilva perdasilva@redhat.com

Description of the change:
Adds possibility to override operator deployment pod affinity.
Pulls in latest commit of api as pseudo-version. Will update to api version once this is good. Subscription.config now contains affinity. To override values:

affinity:
  nodeAffinity: // override with new nodeAffinity definition in deployment
    ... 
  podAffinity: {} // remove podAffinity definition from deployment

or

affinity: {}  // completely remove affinity definition from deployment

I used reflections to automatically capture any affinity changes in the API coming from upstream kube

Motivation for the change:
Help schedule operators in multiarch environments

Architectural changes:
N/A

Testing remarks:
Not adding e2e since that would really just test the kube scheduler. Opted for more aggressive unit testing to ensure the spec is modified properly. I've also done some manual testing against a kind cluster with two nodes, manipulating namespace labels and including dummy pods to test out the node, pod, and pod anti- affinity settings. Seems to work.

Reviewer Checklist

• Implementation matches the proposed design, or proposal is updated to match implementation
• Sufficient unit test coverage
• Sufficient end-to-end test coverage
• Bug fixes are accompanied by regression test(s)
• e2e tests and flake fixes are accompanied evidence of flake testing, e.g. executing the test 100(0) times
• tech debt/todo is accompanied by issue link(s) in comments in the surrounding code
• Tests are comprehensible, e.g. Ginkgo DSL is being used appropriately
• Docs updated or added to /doc
• Commit messages sensible and descriptive
• Tests marked as [FLAKE] are truly flaky and have an issue
• Code is properly formatted

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: perdasilva

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 [perdasilva]

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

[timflannagan]

Can we split the o-f/api bump from the code changes here?

[perdasilva]

Can we split the o-f/api bump from the code changes here?

For no one but you, @timflannagan

[exdx]

Should we bother overwriting the affinity in this case? I just wonder if we're going to encounter more conflict type errors needlessly? We could just return early here.

[perdasilva]

That's basically the semantic of the empty/default override. I.e.

Subscription looking like

config:
  affinity: {}

should end up as a pod spec w/o affinity. I guess the alternative would be to have something like:

affinity: {}

in the podSpec. But that felt kinda dangly to me. wdyt?

[perdasilva]

I also think this should be safe. As affinity: {} -> corev1.Affinity{} - right?

[exdx]

Do we need to use ValueOf if these types are not interfaces? Couldn't we just dereference them normally?

[perdasilva]

The point of this code was to handle API changes dynamically. I've updated to remove most of the reflection stuff and make it more readable/maintainable. I've added a unit test to detect whether there are been API changes and fail CI with a helpful message of what to do.

[timflannagan]

/lgtm