Support objectSelector on mutating webhook

[Cian911]

🛑 Important:

Please open an issue to discuss significant work before you start. We appreciate your contributions and don't want your efforts to go to waste!

For guidelines on how to contribute, please review the CONTRIBUTING.md document.

Purpose of this PR

When the jobs are run for the spark-operator in the same namespace in which the operator resides, the operator will attempt to mutate itself.

Proposed changes:

• This PR adds support for specifying an objectSelector on the MutatingWebhookConfiguration so as a user can specify what pods matching a given set of labels the operator can mutate. See also related issue requesting this.
• This PR also updates the minikube CI action to the latest release. This has been moved to this PR.

Change Category

Indicate the type of change by marking the applicable boxes:

• Bugfix (non-breaking change which fixes an issue)
• Feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that could affect existing functionality)
• Documentation update

Rationale

Checklist

Before submitting your PR, please review the following:

• I have conducted a self-review of my own code.
• I have updated documentation accordingly.
• I have added tests that prove my changes are effective or that my feature works.
• Existing unit tests pass locally with my changes.

Additional Notes

[Cian911]

Looks like the CI failures caused as a result of minikube kubernetes/minikube#18021

[yuchaoran2011]

This is a great addition. But can we limit each PR to a specific goal only (e.g. moving the CI action change to another PR)? That way, it's easier to troubleshoot and revert if needed.

[Cian911]

This is a great addition. But can we limit each PR to a specific goal only (e.g. moving the CI action change to another PR)? That way, it's easier to troubleshoot and revert if needed.

Sure thing, I can move the CI change to a different PR. I just made the change to ensure the CI would pass.

I'll do that now, which will need to be merged in first 👍

[Cian911]

@yuchaoran2011 I have removed the change from this PR (hence why some actions are failing), and moved it to this PR. This new PR will need to be merged first, then this one rebased afterwards.

[vikas-saxena02]

@yuchaoran2011 I have removed the change from this PR (hence why some actions are failing), and moved it to this PR. This new PR will need to be merged first, then this one rebased afterwards.

Thanks @Cian911 I was just about to open another bug as the current CI is failing. @yuchaoran2011 @andreyvelich @vara-bonthu can we please merge this PR on a priority

[Cian911]

@yuchaoran2011 @vara-bonthu Now that my other PR has been merged with regards to the minikube CI issue, this PR should be good to go, if I can get a review/approval 🙏

[vara-bonthu]

PR looks good to me. Could you confirm if your local tests are successful?

[Cian911]

PR looks good to me. Could you confirm if your local tests are successful?

Yes indeed, we are already using this in our clusters, see below:

I've also just updated the chart version & docs again following the most recent merge. It would be great if any of you can review this again 🙇 cc: @vara-bonthu @yuchaoran2011

[yuchaoran2011]

/lgtm

[google-oss-prow]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: yuchaoran2011

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

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