Skip to content

Split RunTarget/Component config from LaunchManager config? #396

Description

@NicolasFussberger

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)

  • Decision taken

How

No response

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    Projects

    Status
    Backlog

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions