search

canonical / operator

Pure Python framework for writing Juju charms
Apache License 2.0
246 stars 119 forks source link

Custom Application Level Events and Triggers #437

Closed balbirthomas closed 1 year ago

balbirthomas commented 4 years ago

Use Case

The operator framework and Juju provide a useful set of application lifecycle events that charms use in managing their application states. These pre-defined events satisfy most of the use cases. However there are instances when there is a need to create custom events and triggers for these events. Consider a few examples to illustrate this

  1. When deploying clusters (groups) of a distributed application, there can be a lag between the time when a Kubernetes readiness probe passes and the time when a newly added unit actually gets discovered by the cluster. In such as case the charm may need to respond when the newly added unit has actually been discovered by the existing cluster rather than just when its readiness probe passes. It is possible to use the update status hook if such a lag is present only at deployment time. However if the lag also occurs during scale up and scale down then the 5 min interval of the update status may be too slow.
  2. Many applications have the ability to raise alerts. Usually such alerts are handled by other applications (deployed by related charms). However some times a charm may need to take action in response to such an alert.

Custom Events and Triggers

Use cases such as those listed above can be handled by charms if the following two features were available

  1. The ability of a charm to register a predicate function (boolean return value) along with an event name and a polling interval, such that the named event is triggered when the predicate returns true.
  2. An URI endpoint (web hook) in Juju to which an application may forward an event and the ability of a charm to register as an observer to such events.
facundobatista commented 4 years ago

Hello @balbirthomas! Is this really an enhancement for the Operator Framework, or a feature idea for Juju itself?

chipaca commented 4 years ago

I think what you're calling 'Level Events' are what we've called 'dependencies' in #329.

johnsca commented 3 years ago

@chipaca It's not exactly the same. The Dependency proposal is more about collecting a group of conditions together with a cleaner UX where the individual conditions (at least all the ones listed in that example) are notified by existing Juju-triggered hooks. Whereas the custom application-level events proposed here seem to be more about having charm code called based on external triggers which are not modeled by Juju.

I think something like this has been discussed here and there in the past with the main limitation being the need for a hook context. The closest approximation I think we have today is having the charm start a background service which watches for the condition and calls the juju-run hook tool, which can be used to trigger a custom event by faking the JUJU_DISPATCH_PATH environment variable. Obviously, that's pretty hacky and I'm not sure if that approach would work on a Kubernetes charm, though. A cleaner solution would definitely require some additional support from Juju itself.

benhoyt commented 1 year ago

Part of this is a Juju bug -- which will be handled with the upcoming Pebble Notices (aka Pebble Events) feature.

From the OF side, you can run ./dispatch with the JUJU_DISPATCH_PATH env var set to "hooks/custom_name" and it will execute the event.