Reduce command line flag boilerplate

[DirectXMan12]

We've so far been somewhat CLI-agnostic in controller runtime. However, considering that this is a common task, we may wish to set up some optional helpers (i.e. a pattern) for per-controller flag setup.

This pattern helps make controllers more distinct, which makes it easier to refactor large controllers managers out into smaller ones, choose to run certain controllers, but not all, and can clarify controller setup. It should be advantageous for larger controllers, but not necessarily mandatory for quickly getting up and running.

Something so that you can basically do:

type ControllerOneInit struct {
    Flag1 bool `flag:"flag-one"`
    Flag2 bool `flag:"flag-two"`
}

func (c *MyController) Register(mgr manager.Manager) error {
    return builder.SimpleController().
       ...
       .WithManager(mgr).
       .Reconcile(ControllerOne{
         Option1: c.Flag1,
         Option2: fmt.Sprintf("%v", c.Flag2),
       }).Build()
}

// elsewhere
func main() {
   builder.SimpleManager().
     Controller(&ControllerOneInit{}).
     ...
     .Run(signal.SetupSignals())
}

Perhaps this could be simplified (avoiding the separation between raw options and controller fields) to

type ControllerOne struct {
    Option1 bool `flag:"flag-one"`
    Option2 string `flag:"flag-two"`

    client.Client
}

func (c *ControllerOne) Register(mgr manager.Manager) error {
    return builder.SimpleController().
       ...
       .WithManager(mgr).
       .Reconcile(c).Build()
}

// elsewhere
func main() {
   builder.SimpleManager().
     Controller(&ControllerOne).
     ...
     .Run(signal.SetupSignals())
}

But the separation between raw options and controller fields may be advantageous enough to warrant the extra separation.

cc @cheftako

[DirectXMan12]

/kind feature
/priority backlog

[fejta-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 sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[fejta-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 sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten

[DirectXMan12]

/remove-lifecycle rotten

cc @luxas re componentconfig

[fejta-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 sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[DirectXMan12]

/lifecycle frozen

see also #518

[vincepri]

Closing, superseded by #518 and friends

/close

[k8s-ci-robot]

@vincepri: Closing this issue.

In response to this:

Closing, superseded by #518 and friends

/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.