Metacontroller Roadmap (2018)

[enisoc]

This is a tentative outline of future plans for Metacontroller.

See the project board for the status of individual tasks. The backlog there is split into three columns:

• Proposed: Not fleshed out enough to implement yet. Needs discussion.
• Blocked: We know what to do, but it has to wait for something external to happen.
• Ready: We're ready to do this, but no one has picked it up yet.

Q1 2018

• [x] Add example to demonstrate building an Operator with Metacontroller.
  • [x] Vitess Operator example.
• [x] Work towards Alpha release.
  • [x] Remove warning about running in real clusters.
    • [x] Cache discovery info.
    • [x] Use watches (informers) for Metacontroller API objects.
    • [x] Use watches (informers) for arbitrary objects.
    • [x] Parallelize controllers hosted by Metacontroller.
  • [x] Internal refactors.
    • [x] Break up main package, restructure to support multiple controller patterns.
    • [x] Generate a client and informer set for Metacontroller APIs.

Q2 2018

• [x] Alpha release.
  • [x] Document alpha API for k8s objects (e.g. CompositeController) and corresponding webhook objects (Request/Response).
  • [x] Document how to debug controllers when developing with Metacontroller.
  • [x] Document best practices for developing controllers with Metacontroller.
  • [x] Smoke tests.
• [ ] Work towards Beta release.
  • [ ] Emit events on controller parent objects.
  • [ ] Use leader election to prevent fighting among multiple Metacontroller instances (optionally enable HA).
  • [ ] Full regression test suite (unit, integration, e2e).
• [ ] Support more controller patterns (in addition to CompositeController).

Q3 2018

• [ ] Beta release.
  • [ ] API is a candidate for GA, although there could still be breaking changes if necessary.
  • [ ] Scalability benchmarks.
    • [ ] Consider sharding if significant bottlenecks are found.
  • [ ] Support mutual authentication of webhook requests.
  • [ ] Support least privilege (e.g. ServiceAccount per controller).

Q4 2018

• [ ] 1.0 release.
  • [ ] API will be backward compatible in future 1.x.y releases.
  • [ ] Clean up dependencies (share code instead of copying from k8s/k8s).
  • [ ] Support installing/updating through k8s add-on manager.

[bgrant0607]

Have you thought about a meta admission controller for validation, defaulting, and policy enforcement?

[enisoc]

I have thought about those, but I don't think they would have much in common with Metacontroller other than the general principle of offering limited, declarative interfaces as an alternative to writing code with full control. Metacontroller is the result of applying that principle specifically to reconciliation loops; admission control plugins are a different model (synchronous decisions) so I would see meta-admission as a separate project/binary.

I think PodPreset is an example of applying this principle to a subset of policy enforcement. The other examples I've thought about include more opinionated, declarative interfaces for CRD validation/defaulting/conversion. For example, core k8s might never support conversion operations other than no-op and field rename, but if support for webhook conversion lands, it will be possible to write a meta-conversion-webhook that lets you do more things declaratively like scalar<->vector, type conversion, split/join, shift/transpose nesting levels, etc.

Similarly, with dynamic admission webhooks, it's possible today to create meta-validation and meta-defaulting that offers an alternative interface to OpenAPIV3.