-
Notifications
You must be signed in to change notification settings - Fork 18
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Refactor termination policy #442
Comments
9 tasks
13 tasks
mostafa
added a commit
that referenced
this issue
Mar 1, 2024
This giant PR adds the very first version of the Act system that was proposed in [this proposal](gatewayd-io/proposals#5). The old way of signaling was static and only supported a single signal: `terminate`. The new system support more signals, adds proper policies that can be easily controlled by the users and the actions are executed in sync and async mode. The Act system consists of these components: 1. **Act Registry**: takes care of registering signals, policies and actions. It also applies policies to signals to produce outputs for actions and runs actions using those outputs. 2. **Signals**: plugins' hooks can return signal(s) as part of their request/response. These signals tell GatewayD what to do. 3. **Policies**: signals pass through predefined policies that will decide whether GatewayD should react to the signal or not. 4. **Actions**: actions run in sync or async mode and perform a function. Sync actions are used to control traffic (passthrough, terminate, etc.) and other parts of the system, and async actions can other things (log, publish a message to Kafka, etc.). 5. **Plugin Registry**: after running a hook on each plugin, the signals are extracted and the policies are applied to those signals. The output of those policy evaluations are returned to the caller, which knows how to run action and use its results. And the code spans over two projects: 1. **GatewayD**: all the above components of the Act system are in GatewayD. 2. **SDK**: types and helper functions for creating and exporting signals are in the SDK. ### Breaking changes The old way of terminating requests don't work anymore, as it was refactored in #442 and all the plugins are updated to pick up the changes.
Merged
13 tasks
smnmna99
pushed a commit
that referenced
this issue
Mar 13, 2024
This giant PR adds the very first version of the Act system that was proposed in [this proposal](gatewayd-io/proposals#5). The old way of signaling was static and only supported a single signal: `terminate`. The new system support more signals, adds proper policies that can be easily controlled by the users and the actions are executed in sync and async mode. The Act system consists of these components: 1. **Act Registry**: takes care of registering signals, policies and actions. It also applies policies to signals to produce outputs for actions and runs actions using those outputs. 2. **Signals**: plugins' hooks can return signal(s) as part of their request/response. These signals tell GatewayD what to do. 3. **Policies**: signals pass through predefined policies that will decide whether GatewayD should react to the signal or not. 4. **Actions**: actions run in sync or async mode and perform a function. Sync actions are used to control traffic (passthrough, terminate, etc.) and other parts of the system, and async actions can other things (log, publish a message to Kafka, etc.). 5. **Plugin Registry**: after running a hook on each plugin, the signals are extracted and the policies are applied to those signals. The output of those policy evaluations are returned to the caller, which knows how to run action and use its results. And the code spans over two projects: 1. **GatewayD**: all the above components of the Act system are in GatewayD. 2. **SDK**: types and helper functions for creating and exporting signals are in the SDK. ### Breaking changes The old way of terminating requests don't work anymore, as it was refactored in #442 and all the plugins are updated to pick up the changes.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The current termination policy relies on the boolean
terminate
to be passed from the plugin to GatewayD, while the changes in #422 requires it to be sent to GatewayD as a signal (in the list of signals). Refactoring this involves changing all the plugins and docs.The text was updated successfully, but these errors were encountered: