Apply Subscription.Spec.Config.Annotations to Deployments, Pods, ApiServices

[cognifloyd]

Description of the change:

Use Subscription.Spec.Config.Annotations to apply admin-supplied annotations to an Operator's:

• Deployments
• Pods (via Deployment Spec)
• ApiServices

Motivation for the change:

I need a way to annotate operator deployments to satisfy an admissions hook in my on-prem vanilla (not OCP) k8s clusters (The admissions hook requires annotations that say which team is responsible for that deployment).

After discussing in #olm-dev, it looks like Subscription is the best user (cluster admin) facing API to extend for this purpose, as other resources, like CSV, should generally be opaque to the cluster admin.

So, I added Annotations to SubscriptionConfig in: operator-framework/api#312
That was released in v0.22.0.

Architectural changes:

N/A

Testing remarks:

No testing yet. I need feedback on this before I do anything else.

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]

Hi @cognifloyd. Thanks for your PR.

I'm waiting for a operator-framework member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[openshift-ci]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: cognifloyd
Once this PR has been reviewed and has the lgtm label, please assign joelanford for approval. 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:

• OWNERS

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

[grokspawn]

/ok-to-test

[stevekuznetsov]

Do you own the definition of your validating admission webhook? It strikes me as easier to ensure that Subscriptions have the ownership annotations you need and exclude Deployments that have OLM management labels.

[stevekuznetsov]

These changes look good, perhaps @joelanford can do a review here for direction.

[cognifloyd]

I just force pushed to signoff my commit and satisfy the DCO check.

[cognifloyd]

Do you own the definition of your validating admission webhook? It strikes me as easier to ensure that Subscriptions have the ownership annotations you need and exclude Deployments that have OLM management labels.

Yes and no. Yes, my team manages the admissions webhook, but the policy on inspecting Deployments was defined by an audit team. So, just modifying that admissions webhook won't satisfy the auditor's policy which ties my hands.

[kevinrizza]

/lgtm
/approve

[kevinrizza]

👍