First-start reconcilation loop

[shanesveller]

Disclaimer: Code links are merely for my own reference and other less-familiar readers, and are by no means meant to imply that the maintainer does not know the contents of their own codebase. 😄

Environment

• Bonny version: 0.2.3
• Elixir & Erlang/OTP versions (elixir --version): (any supported)
• Operating system: (any supported)

Current behavior

The current Bonny.Controller behaviour defines the add, modify and delete callbacks and includes these three events in the mix bonny.gen.controller templating.

Expected behavior

I would like to propose an additional callback of reconcile (or another representative terminology) that will, during the first boot cycle and again periodically on a configurable timer, examine existing CRDs within the operator's purview. Then it will ensure that any appropriate action has been taken based on their contents, i.e. that managed descendent resources exist with the desired content. With an eye for as much idempotency as possible, it should correct any configuration drift that may have happened while a Bonny-based operator was offline, misbehaving, etc.

This is a common practice in other operator codebases and frameworks, and would help enable the declarative, convergent behavior that we've come to appreciate from standard Kubernetes primitives.

Other notes

The current Bonny.Watcher implementation short-circuits the review of existing resources that match the watch request within the Bonny.Watcher.Impl module, which on the first request without a resource version:

Defaults to changes from the beginning of history

This feature probably also depends on #27 for clean access to the /status subresource to make it truly graceful to handle pre-existing CRDs which have already been realized.

Finally, I have half-formed ideas of trying this on my own project that may result in a PR here for discussion purposes, but I'm not yet using this library at work and will have difficulty committing the time soon.

[coryodaniel]

This sounds like a good option if the function is defined by a user, the Watcher can start a timer to call it periodically.

Re: the beginning of time, I was planning to bump a minor version when I migrate to k8s library. When doing this I was also going to change the default from beginning of time to the “current” revision stamp.

[shanesveller]

Regarding the very last point, I'm not certain based on the phrasing, but I think it might be counter to the goal I was expressing with this issue. In short, when my operator starts up, I want an opportunity to examine all existing CRDs that my operator is interested in, ideally without firing an extra request to fetch this history. The very first request the library performs upon launch already includes the information I'm after, it's just discarded after the latest resource version is parsed rather than passed on anywhere else.

[coryodaniel]

Ahhh! I gotcha. Yes that would be a cool! Thanks, Cory O’Daniel

…

On Mar 6, 2019, at 8:42 AM, Shane Sveller ***@***.***> wrote: Regarding the very last point, I'm not certain based on the phrasing, but I think it might be counter to the goal I was expressing with this issue. In short, when my operator starts up, I want an opportunity to examine all existing CRDs that my operator is interested in, ideally without firing an extra request to fetch this history. The very first request the library performs upon launch already includes the information I'm after, it's just discarded after the latest resource version is parsed rather than passed on anywhere else. — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.