... | ... | @@ -236,7 +236,6 @@ The proposed solutions: |
|
|
- Using the settings table in the database
|
|
|
- Using API
|
|
|
- Integration with existing configuration
|
|
|
|
|
|
### Using environment variables
|
|
|
|
|
|
In this scenario, the configuration parameters are passed using the environment variables. The hooks should use the unique prefix to avoid collisions. The valid parameters must be described by the hook documentation and validated during the hook loading. The hook can read the Stork core variables too.
|
... | ... | @@ -259,6 +258,14 @@ The hook can provide a custom REST or gRPC endpoint to configure. It may be help |
|
|
|
|
|
The hook provides a function that returns the CLI flags. This function is called before hook loading and agent/server initializing. The hook CLI flags are merged with the core CLI flags. It causes that they are presented, validated, and handled in the same way as standard flags. The parsed input flag values are passed to the hook's load function. Our CLI framework supports providing the parameters as CLI arguments or environment variables
|
|
|
|
|
|
### Hook loading time
|
|
|
|
|
|
The first time when the hooks are loaded is the server setup phase. The hook manager should load all hooks from the specific directory.
|
|
|
It's possible to watch on the hook directory. When the user pastes the new hook library, the application can load it automatically. If it isn't an expected behavior, the new hooks may be loaded on demand (e.g., requested via the RESTApi).
|
|
|
|
|
|
The first time when the hooks are loaded is the server setup phase. The hook manager should load all hooks from the specific directory.
|
|
|
It's possible to watch on the hook directory. When the user pastes the new hook library, the application can load it automatically. If it isn't an expected behavior, the new hooks may be loaded on demand (e.g., requested via the RESTApi). The look loaded in runtime cannot use the CLI parameters, but it still can read environment variables or query the settings database.
|
|
|
|
|
|
### Comparison
|
|
|
|
|
|
| Solution | Supports envvars | Supports CLI params | Has CLI help | Supports re-configuration in runtime | Has strict form | Supports third-party control | Requires built-in support | Difficult for hook authors |
|
... | ... | @@ -277,6 +284,8 @@ We also need the possibility to re-configure the hooks in runtime. We should uti |
|
|
|
|
|
I think the above solutions should be enough for most cases, and we can start with them. Additionally, other solutions may be implemented internally in the hooks without dedicated support in the core.
|
|
|
|
|
|
The hook shouldn't depend on how the settings were provided. The parameters provided from the command line and RestAPI should be generalized. It should be possible to override the CLI values with ones from the API request.
|
|
|
|
|
|
## Hook data sharing
|
|
|
|
|
|
Sharing or exchanging data between the hooks registered on the same callout may be beneficial. It allows controlling the processing flow from inside the hooks and covers advanced cases. The hook may communicate with each other to avoid collisions or doubled results. On the other hand, the hooks may be chained to sequentially analyze the data and make a single decision returned to the core.
|
... | ... | @@ -291,6 +300,8 @@ The handling of hook communication will be the responsibility of the `Hook Execu |
|
|
|
|
|
We have a special `context.Context` structure in Go. It is a bag for variety, unstructured data. We can assume that each callout point will accept the context object. The same context instance will be passed to each hook sequentially. It allows hook's authors to internally manage the structure of the context and data exchange rules. The core will be only responsible for creating the context object and will know nothing about its content.
|
|
|
|
|
|
The context provides the timeout feature. It may be used to interrupt hooks that execute too long.
|
|
|
|
|
|
### Exchange data using callout signature
|
|
|
|
|
|
In this case, the data sharing is controlled by the core. It means that the core knows the data meaning and may interrupt the hook execution or modify the data between calling the callout points.
|
... | ... | |