mirror of
https://github.com/fleetdm/fleet
synced 2026-05-11 03:00:58 +00:00
643fc8314b
New interface for adding periodic jobs that rely on notifications/config
changes in Orbit.
Previously if we wanted to have recurring checks in Orbit, we would add
them into a chain of `GetConfig` calls. This call chain would be run
periodically by one of the runners registered with the cli application
framework.
The new method to register `OrbitConfigReceivers` with the
`OrbitClient`, and then register the orbit client itself with the
application framework.
Instead of having giving each fetcher an internal reference to the
previous fetcher that it must call, the receiver is registered with the
client and the new config is passed to the receiver.
This is the old `GetConfig()` interface:
```go
type OrbitConfigFetcher interface {
GetConfig() (*fleet.OrbitConfig, error)
}
```
This is the new `OrbitConfigReceiver` interface:
```go
type OrbitConfigReceiver interface {
Run(*OrbitConfig) error
}
```
To register a new receiver, you call the `RegisterConfigReceiver` method
on the client.
```go
orbitClient.RegisterConfigReceiver(extRunner)
```
Downsides of the old method:
- Spaghetti call chain setup
- Cascading failure, of one fails, all after it fail
- Run in series, one long function call holds up the rest
- Anything that wants to restart orbit is added as a Runner to the
application, meaning there could be several timers calling `GetConfig`
and running the chain
Benefits of the new method:
- Clean `RegisterConfigReceiver` api, no call chaining required
- Config receivers can be added at runtime
- Isolated receivers, one failing call don't effect others
- All calls are run in parallel in goroutines, no calls can hold up the
rest
- No more need for multiple runners, using a context cancel, any
receiver can queue a call to restart orbit
- Single point to handle errors and logging for all receivers
- Panic recovery to stop orbit from crashing
- Easier to test, configs are passed in and do not require a call chain
This branch contains a little bit of code from the installer method I
was working on because I branched it off of that. (oops)
Not all code comments surrounding old `GetConfig()` methods have been
fully updated yet
Possible changes:
- Update the interface to take a context, so we can let receivers know
to exit early. I can imagine two cases for this:
- The application is about to restart
- We can set a timeout for how long receivers are allowed to take
Closes #12662
---------
Co-authored-by: Martin Angers <martin.n.angers@gmail.com>
Co-authored-by: Roberto Dip <dip.jesusr@gmail.com>
|
||
|---|---|---|
| .. | ||
| badgerstore | ||
| filestore | ||
| config_fetcher.go | ||
| disk_encryption.go | ||
| execcmd.go | ||
| execcmd_darwin.go | ||
| execcmd_stub.go | ||
| execwinapi.go | ||
| execwinapi_stub.go | ||
| execwinapi_windows.go | ||
| file.go | ||
| flag_runner.go | ||
| flag_runner_test.go | ||
| hash.go | ||
| hash_test.go | ||
| notifications.go | ||
| notifications_test.go | ||
| nudge.go | ||
| nudge_test.go | ||
| options.go | ||
| options_darwin.go | ||
| options_linux.go | ||
| options_windows.go | ||
| runner.go | ||
| runner_test.go | ||
| swift_dialog.go | ||
| swift_dialog_test.go | ||
| testing_utils.go | ||
| update.go | ||
| update_test.go | ||