What
Problem
Currently, the Launch Manager is configured with a single json file that mixes the RunTarget/Component configuration with Launch Manager daemon configuration (initial run target, alive monitoring thread periodicity, watchdog, ..).
Once we want to support multiple configuration files, this may become a problem.
While there may be an arbitrary number of RunTargets/Components defined in different files, the Launch Manager daemon settings must exist at most once.
This may create conflicting situations at runtime:
Example:
Config File 1:
- initial run target: "Target1"
Config File 2:
- initial Run Target: "Target2"
What initial run target shall launch manager use? First config file loaded wins?
Currently, only few launch manager daemon settings are configurable, but in the future we need to add more settings:
- Alive monitoring thread periodicity
- initial run target
- fallback run target
- scheduling policy of launch manager
- scheduling priority of launch manager
- number of worker threads
- security policy for launch manager
- core affinity for launch manager threads
- Launch Manager main loop cycle time
- ...
Solution Ideas
Option 1: Move launch manager daemon configuration to a separate configuration file
- Introduce a second configuration file containing all launch manger daemon configuration
- The file must exist at most once in the filesystem and is loaded at startup
- The file is optional, defaults are used when values are not configured or file is not available
Option 2: Move launch manager daemon configuration to CLI options
- Make the launch manager daemon configuration into CLI options
- Use defaults if option is not provided
Example:
launch_manager -w <number of worker threads> -i <initial_run_target> -f <fallback_run_target> ...
-w <number of worker threads> : default 8
-i <initial run target> : default "Startup"
-f <fallback_run_target> : default "fallback"
- ...
Option 3: Keep launch manager daemon configuration in the existing json schema, but separate it in a dedicated object
- Keep everything together in a single json schema
- Separate the launch manager daemon specific settings in a dedicated object (called "daemon" below)
- The "daemon" section must only exist in a single json file can only be available in the set of initial config files
- If "daemon" section is encountered in any further config file, the config file is rejected (no merging of settings)
Example:
{
"components": [...],
"run_targets": [...],
"daemon" : {
"initial_run_target": "abc",
"scheduling_policy": "SCHED_RR",
....
}
}
Acceptance Criteria (DoD)
How
No response
What
Problem
Currently, the Launch Manager is configured with a single json file that mixes the RunTarget/Component configuration with Launch Manager daemon configuration (initial run target, alive monitoring thread periodicity, watchdog, ..).
Once we want to support multiple configuration files, this may become a problem.
While there may be an arbitrary number of RunTargets/Components defined in different files, the Launch Manager daemon settings must exist at most once.
This may create conflicting situations at runtime:
Example:
Config File 1:
Config File 2:
What initial run target shall launch manager use? First config file loaded wins?
Currently, only few launch manager daemon settings are configurable, but in the future we need to add more settings:
Solution Ideas
Option 1: Move launch manager daemon configuration to a separate configuration file
Option 2: Move launch manager daemon configuration to CLI options
Example:
launch_manager -w <number of worker threads> -i <initial_run_target> -f <fallback_run_target> ...-w <number of worker threads>: default 8-i <initial run target>: default "Startup"-f <fallback_run_target>: default "fallback"Option 3: Keep launch manager daemon configuration in the existing json schema, but separate it in a dedicated object
Example:
{ "components": [...], "run_targets": [...], "daemon" : { "initial_run_target": "abc", "scheduling_policy": "SCHED_RR", .... } }Acceptance Criteria (DoD)
How
No response