Support loading controller configuration from a versioned file

[irbekrm]

Support loading controller configuration from a versioned file by adding a new API type containing the existing controller configuration options as fields and allowing a user to optionally pass a configmap containing this API object (as well as continuing to support the current flag-based configuration mechanism (but not both at the same time)).

For context see documentation for a mechanism that allows upstream Kubernetes components to support loading config from versioned files

In cert-manager we would also like to allow for component (webhook, controller, cainjector configuration to be loaded from versioned files).
This should help with cases such as #4489

In #4546 we already implemented support for loading webhook configuration from a versioned file by adding a new WebhookConfiguration API type that can be provided to cert-manger webhook in configmap- this issue is for implementing the same change for cert-manager controller

Rough outline of steps required (there will likely be a need to do some additional things/do some things differently):

• Add a new ControllerConfiguration type to the v1alpha1.config.cert-manager.io API group + related code to add the new type to the schema, this should be very similar to fb81666
• Populate the new type with fields corresponding to the current controller options. Implement existing defaulting, but using defaulting functions registered for the type (see how it's done for the webhook - a defaulting function gets registered using autogenerated defaulting code with defaulter-gen. This change was done for webhook in afa8e5a (that also contains some other changes)
• Refactor controller command and running and initialization of the controller to use values (including defaults) from ControllerConfiguration. This change will likely be similar to afa8e5a
• Add a fuzz function for ControllerConfiguration type to config fuzzer tests similar to how it was done in 415ca56
• Add a test to check correct precedence of controller flags vs config values like it was done in e21c6e6
• Add a unittest for configfile loading like in 71a69cc
• Add support for configmap with the new API type to helm chart similar to how it was done for webhook in 553e1e0

/kind feature

[irbekrm]

I am marking this issue as 'help wanted'- contributions very welcome!

I think it could be interesting for anyone wanting to understand the concerns around configuring/initializing components that are meant to be deployed on Kubernetes (specifically controllers and webhooks), work done towards building a better mechanism for that upstream
as well as adding a new type to an external Kubernetes API and writing tests for it.

This is not really a beginner issue- ideally the person picking it up will have had some experience/understanding of Go CLIs and a bit of experience/exposure to Kubernetes controllers.

[AcidLeroy]

@irbekrm I'll start taking a look, thanks for proposing this!

[AcidLeroy]

For context see documentation for a mechanism that allows upstream Kubernetes components to support loading config from versioned files

@irbekrm I don't have access to this document.

[irbekrm]

Hey @AcidLeroy , I don't have access to my laptop right now (bank holidays here in the UK) but I think you need to join Kubernetes dev group to access that https://groups.google.com/a/kubernetes.io/g/dev

Let me know if you still cannot access

[AcidLeroy]

Thank you, @irbekrm, that was the secret to viewing the doc. I appreciate it!

[AcidLeroy]

@irbekrm is it possible to assign this issue to me?

[irbekrm]

Hey @AcidLeroy , yes of course, thanks for showing interest in this, it would be a really valuable addition!

/assign @AcidLeroy

[jetstack-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close.
Send feedback to jetstack.
/lifecycle stale

[jetstack-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
If this issue is safe to close now please do so with /close.
Send feedback to jetstack.
/lifecycle rotten
/remove-lifecycle stale

[jetstack-bot]

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.
Send feedback to jetstack.
/close

[jetstack-bot]

@jetstack-bot: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.
Send feedback to jetstack.
/close

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.

[irbekrm]

/reopen
/remove-lifecycle rotten

[jetstack-bot]

@irbekrm: Reopened this issue.

In response to this:

/reopen
/remove-lifecycle rotten

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.

[irbekrm]

WIP PR #5337

[irbekrm]

Related Slack discussion https://kubernetes.slack.com/archives/CDEQJ0Q8M/p1658744207696159

[jetstack-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close.
Send feedback to jetstack.
/lifecycle stale

[jetstack-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
If this issue is safe to close now please do so with /close.
Send feedback to jetstack.
/lifecycle rotten
/remove-lifecycle stale

[AcidLeroy]

/remove-lifecycle rotten
/remove-lifecycle stale