... | @@ -197,6 +197,55 @@ The hook loader searches for the hook libraries in the directory specified by th |
... | @@ -197,6 +197,55 @@ The hook loader searches for the hook libraries in the directory specified by th |
|
|
|
|
|
The hook manager hides all details of the hook solution. The code that calls the callout point doesn't matter if a specific hook is registered or how many hooks implement it.
|
|
The hook manager hides all details of the hook solution. The code that calls the callout point doesn't matter if a specific hook is registered or how many hooks implement it.
|
|
|
|
|
|
|
|
## Hook configuration
|
|
|
|
|
|
|
|
The section discusses the possibilities of the hook configuration. We need to analyze how easy and similar to the current solution the configuration will be. The configuration ways may have different capabilities, applicable for different kinds of hooks.
|
|
|
|
|
|
|
|
The proposed solutions:
|
|
|
|
|
|
|
|
- Using environment variables
|
|
|
|
- Using external files
|
|
|
|
- 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.
|
|
|
|
|
|
|
|
### Using external files
|
|
|
|
|
|
|
|
The configuration parameters are read from the external configuration file. The file path can be hardcoded or passed as an environment variable. There are no strict requirements for a specific file format, but we should choose recommended one. The hook should manage the configuration file processing. We can provide some utilities for the recommended format. There is possible to watch for the file changes and reload the configuration.
|
|
|
|
|
|
|
|
### Using the settings table in the database
|
|
|
|
|
|
|
|
The settings table is generic and may store integers, bools, or strings. We need only provide a solution to use the unique prefix for the setting names to avoid collisions. This solution can easily update the configuration parameters without reloading the hook.
|
|
|
|
|
|
|
|
### Using API
|
|
|
|
|
|
|
|
The hook can provide a custom REST or gRPC endpoint to configure. It may be helpful for hooks that integrate Stork with third-party applications. They can dynamically control the hook behavior depending on external conditions.
|
|
|
|
|
|
|
|
### Integration with existing configuration
|
|
|
|
|
|
|
|
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
|
|
|
|
|
|
|
|
### 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 |
|
|
|
|
| :------- | :--------------: | :-----------------: | :----------: | :----------------------------------: | :-------------: | :---: | ---: | -------------------------: |
|
|
|
|
| Using environment variables | YES | NO | NO | NO | NO | NO | NO | EASY |
|
|
|
|
| Using external files | NO | NO | NO | YES | NO | YES | NO | HARD |
|
|
|
|
| Using the settings table in the database | NO | NO | NO | YES | YES | YES | YES | MEDIUM |
|
|
|
|
| Using API | NO | NO | NO | YES | NO | YES | NO | VERY HARD |
|
|
|
|
| Integration with existing configuration | YES | YES | YES | NO | YES | NO | YES | MEDIUM |
|
|
|
|
|
|
|
|
### Summary
|
|
|
|
The above comparison shows that no one solution applies to all use cases. We should solve the problem in this way that will cover most of the topics and be easy to use by the authors of hooks.
|
|
|
|
Integrating the hook configuration with the standard configuration will be very convenient. It automatically handles the basic parsing and validation. It also prompts the possible options on standard output. The same solution to configure core and hooks should be the most user-friendly way.
|
|
|
|
We also need the possibility to re-configure the hooks in runtime. We should utilize the setting table. It was designed to store any configuration. It means that it should well handle multiple hook configurations. We can provide an observable pattern to encapsulate the database access and decrease the hook-side effort.
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
## Steps to implement hook
|
|
## Steps to implement hook
|
|
|
|
|
|
1. Look for needed callout points in the hook module
|
|
1. Look for needed callout points in the hook module
|
... | | ... | |