Configuration description for Launch Manager by SimonKozik · Pull Request #54 · eclipse-score/lifecycle

SimonKozik · 2026-01-29T11:42:11Z

Proposal for Launch Manager configuration, that is based on discussion we had so far.

Related to #38

github-actions · 2026-01-29T11:43:10Z

License Check Results

🚀 The license check job ran with the Bazel command:

bazel run //:license-check

Status: ⚠️ Needs Review

Click to expand output

[License Check Output]
Extracting Bazel installation...
Starting local Bazel server (8.4.2) and connecting to it...
INFO: Invocation ID: ebd459ee-7828-4640-858b-e81fe354aee4
Computing main repo mapping: 
Computing main repo mapping: 
Computing main repo mapping: 
Computing main repo mapping: 
Computing main repo mapping: 
DEBUG: Rule 'rust_qnx8_toolchain+' indicated that a canonical reproducible form can be obtained by modifying arguments integrity = "sha256-eQOopREOYCL5vtTb6c1cwZrql4GVrJ1FqgxarQRe1xs="
DEBUG: Repository rust_qnx8_toolchain+ instantiated at:
  <builtin>: in <toplevel>
Repository rule http_archive defined at:
  /home/runner/.bazel/external/bazel_tools/tools/build_defs/repo/http.bzl:431:31: in <toplevel>
Computing main repo mapping: 
Computing main repo mapping: 
Computing main repo mapping: 
Computing main repo mapping: 
Computing main repo mapping: 
Loading: 
Loading: 2 packages loaded
Loading: 2 packages loaded
    currently loading: 
Loading: 2 packages loaded
    currently loading: 
Loading: 2 packages loaded
    currently loading: 
Loading: 2 packages loaded
    currently loading: 
Analyzing: target //:license-check (3 packages loaded, 0 targets configured)
Analyzing: target //:license-check (3 packages loaded, 0 targets configured)

Analyzing: target //:license-check (32 packages loaded, 10 targets configured)

Analyzing: target //:license-check (45 packages loaded, 10 targets configured)

Analyzing: target //:license-check (84 packages loaded, 10 targets configured)

Analyzing: target //:license-check (133 packages loaded, 364 targets configured)

Analyzing: target //:license-check (148 packages loaded, 4012 targets configured)

Analyzing: target //:license-check (150 packages loaded, 7395 targets configured)

Analyzing: target //:license-check (156 packages loaded, 7414 targets configured)

Analyzing: target //:license-check (156 packages loaded, 7414 targets configured)

Analyzing: target //:license-check (156 packages loaded, 7414 targets configured)

Analyzing: target //:license-check (159 packages loaded, 9421 targets configured)

Analyzing: target //:license-check (161 packages loaded, 13556 targets configured)

INFO: Analyzed target //:license-check (162 packages loaded, 13697 targets configured).
[8 / 13] Creating runfiles tree bazel-out/k8-opt-exec-ST-d57f47055a04/bin/external/score_tooling+/dash/tool/formatters/dash_format_converter.runfiles [for tool]; 0s local
[10 / 13] JavaToolchainCompileClasses external/rules_java+/toolchains/platformclasspath_classes; 0s disk-cache, processwrapper-sandbox
[11 / 13] JavaToolchainCompileBootClasspath external/rules_java+/toolchains/platformclasspath.jar; 0s disk-cache, processwrapper-sandbox
INFO: Found 1 target...
Target //:license.check.license_check up-to-date:
  bazel-bin/license.check.license_check
  bazel-bin/license.check.license_check.jar
INFO: Elapsed time: 35.284s, Critical Path: 2.62s
INFO: 13 processes: 9 internal, 3 processwrapper-sandbox, 1 worker.
INFO: Build completed successfully, 13 total actions
INFO: Running command line: bazel-bin/license.check.license_check ./formatted.txt <args omitted>
usage: org.eclipse.dash.licenses.cli.Main [-batch <int>] [-cd <url>]
       [-confidence <int>] [-ef <url>] [-excludeSources <sources>] [-help] [-lic
       <url>] [-project <shortname>] [-repo <url>] [-review] [-summary <file>]
       [-timeout <seconds>] [-token <token>]

github-actions · 2026-01-29T11:44:44Z

The created documentation from the pull request is available at: docu-html

pawelrutkaq

General questions: Since we discuss JSON, we will need again JSON to Flatbuffer tooling? Will this tool be generic or custom for LaunchDaemon ?

So as i remeber, you can for free convert Json to flatbuffers but this requires that it is compatible with fbs schema. Will it be ?

pawelrutkaq · 2026-01-29T15:40:05Z

src/launch_manager_daemon/docs/concepts/configuration.md

general: please use rst in top ./doc folder

Do you want an extra rst file in the doc folder, that will includes this md file?
Or to translate this md file into a rst file?

Keep doc in doc folder so doc-as-code works, so this file shall be rst too.

pawelrutkaq · 2026-01-29T15:44:03Z

src/launch_manager_daemon/docs/concepts/configuration.md

+            "gid" : 1000,
+            "supplementary_group_ids": [500, 600, 700]
+        }
+    }


if we combine deployment configuration with component description in single JSON file, it's not reusable so that separation is rather only for json handling (this contradicts the above explanations).

True. I think the rough workflow that was discussed early January was that the app developer will somehow provide the component-related config + maybe partially the deployment config.

However, since this workflow is currently rather unclear and splitup into multiple files also raised more open points. Therefore, in the last discussion we concluded that as a first step everything shall to into a single file.

But then maybe even in a single json the object should be separated so later splitting it to multiple files does not change schema really.

@pawelrutkaq we were talking internally about this separation as well, but as Nicolas said, a lot of things is unclear.

Just for clarification, are you talking about something like this?

{ "component_configs": { "test_app1": { "is_native_application": false, "is_supervised": true, "is_self_terminating": false, "is_state_manager": false } }, "deployment_configs": { "test_app1": { "startup_timeout": 0.5, "shutdown_timeout": 0.5, "uid" : 1000, "gid" : 1000, "supplementary_group_ids": [500, 600, 700], "scheduling_policy": "SCHED_OTHER", "scheduling_priority": "0" } } }

pawelrutkaq · 2026-01-29T15:53:55Z

src/launch_manager_daemon/docs/concepts/configuration.md

+        },
+        "Full": {
+            "description": "Everything running",
+            "includes": ["Minimal", "test_app1"],


here you lost info who the Minimal or test_app1 is. How you will handle different json object under it in code ?

Do you mean it should be like this?

{ "includes": [ { "run_target": "Minimal" }, { "component": "test_app1" } ] }

Maybe the run_target or component shall have requires "type" keyword, it would be easier to use here as "includes": ["Minimal", "test_app1"],. Then logic can simply relay on querying this type. (still 2 places to lookup needed but that maybe not a problem)

If I understand you correctly you are proposing this:

{ "includes": [ { "type": "run_target", "name": "Minimal" }, { "type": "component", "name": "test_app1" } ] }

As far as I can tell both versions contain the same information, but version in this comment is more verbose (i.e. more unnecessary typing).

If I misunderstood, could you provide some json example of what you are suggesting pls?

I was thinking about something else but maybe the best would be simply:

{ "includes": { "components": [ "Minimal" ], "run_targets": [ "test_app1" ] } }

This way is super clear what is what and parsing is also easy and unambiguous.

FYI: I meant that we keep includes flat "includes":["run", "app"] but this is not really possible, would require that ie no components have the same name as run target etc.

pawelrutkaq · 2026-01-29T15:54:20Z

src/launch_manager_daemon/docs/concepts/configuration.md

+        }
+    },
+    "initial_run_target": "Minimal",
+    "health_monitoring" : {


there is no health_monitoring at LaunchDaemon so shall be removed. is you meant here app supervision, tthe cycle comes via IPC.

This setting is about the evaluation of alive notifications in the launch manager daemon.
Currently, the evaluation is performed in a cycle. E.g. every 50ms launch_manager wakes up and is evaluating the checkpoints that have been received in the last 50ms. It would make sense to have this configurable. Depending on the system and the required detection time of failures, this number might be small (maybe 10ms) or big (maybe 100ms).

Otherwise, if the launch_manager would wake up on every received alive notification and do the evaluation immediately - the performance would be too bad if many applications report alive notifications

Yes I get it. But first of all, change the name - highly confusing with other components. Second of all, you mean you use single thread cycled by this value to check alive notifications presence for all processes ?

Current implementation does use a single thread. I guess that could be extended in the future if this is required.

Do you have a suggestion for another name? Both the library and the daemon are doing some kind of health monitoring. But yeah, having the same name is confusing at the moment.

since we said once the api betwen daemon and users app is SupervisorAPI, maybe it shall be supervisor_cycle_time (app_supervision_cycle_time) or something in this manner ?

SimonKozik · 2026-01-30T07:43:55Z

General questions: Since we discuss JSON, we will need again JSON to Flatbuffer tooling? Will this tool be generic or custom for LaunchDaemon ?

So as i remeber, you can for free convert Json to flatbuffers but this requires that it is compatible with fbs schema. Will it be ?

You will need compiler, but this is part of FlatBuffers (https://flatbuffers.dev/flatc/).
Please note that during transition period, there will be translation python script to map new config to the old structure. As communicated earlier, this script will be part of LM repository and dropped later (when c++ code is updated).

pawelrutkaq · 2026-01-30T11:02:48Z

General questions: Since we discuss JSON, we will need again JSON to Flatbuffer tooling? Will this tool be generic or custom for LaunchDaemon ?
So as i remeber, you can for free convert Json to flatbuffers but this requires that it is compatible with fbs schema. Will it be ?

You will need compiler, but this is part of FlatBuffers (https://flatbuffers.dev/flatc/). Please note that during transition period, there will be translation python script to map new config to the old structure. As communicated earlier, this script will be part of LM repository and dropped later (when c++ code is updated).

I am asking after transition, its still unclear since as i said to use flatcc, this config what we do here must be fbs compatible. maybe it is out of box ?

SimonKozik · 2026-01-30T13:59:25Z

General questions: Since we discuss JSON, we will need again JSON to Flatbuffer tooling? Will this tool be generic or custom for LaunchDaemon ?
So as i remeber, you can for free convert Json to flatbuffers but this requires that it is compatible with fbs schema. Will it be ?

You will need compiler, but this is part of FlatBuffers (https://flatbuffers.dev/flatc/). Please note that during transition period, there will be translation python script to map new config to the old structure. As communicated earlier, this script will be part of LM repository and dropped later (when c++ code is updated).

I am asking after transition, its still unclear since as i said to use flatcc, this config what we do here must be fbs compatible. maybe it is out of box ?

Current plan is that after transition, user visible json format will be fbs compatible. Or in other words, during transition we plan to change fbs format, so it becomes compatible with json format we create here.

Finger cross this explain things.

NicolasFussberger · 2026-02-03T06:40:40Z

src/launch_manager_daemon/docs/concepts/configuration.md

+            "is_supervised": false,
+            "is_self_terminating": true
+        },
+        "deployment_config": {


In my opinion it would make sense if - as intermediate solution - we also add here the expectation of alive notifications for the launch manager.

Until we have the new runtime registration mechanism implemented both in the launch_manager and in the health_monitoring_library we need this information from the configuration to keep the current functionality working. Without this information, launch_manager will not know the expected frequency of alive notifications.

Once the runtime registration mechanism is implemented, we can remove it from the configuration again.

Initial configuration draft

799db76

SimonKozik temporarily deployed to workflow-approval January 29, 2026 11:42 — with GitHub Actions Inactive

SimonKozik temporarily deployed to workflow-approval January 29, 2026 15:26 — with GitHub Actions Inactive

pawelrutkaq reviewed Jan 29, 2026

View reviewed changes

SimonKozik added 2 commits January 30, 2026 14:08

Renaming sandbox into deployment_config and adding some justification

0cf32db

Adding transition_timeout to example config

4c4610a

SimonKozik force-pushed the feature/configuration_concept branch from df9301a to 4c4610a Compare January 30, 2026 14:09

SimonKozik temporarily deployed to workflow-approval January 30, 2026 14:09 — with GitHub Actions Inactive

Adding description of supported configuration elements

cafab09

SimonKozik had a problem deploying to workflow-approval February 2, 2026 15:15 — with GitHub Actions Failure

NicolasFussberger reviewed Feb 3, 2026

View reviewed changes

Applying review comments, some cosmetic changes

1c14a84

SimonKozik temporarily deployed to workflow-approval February 3, 2026 15:36 — with GitHub Actions Inactive

Changes discussed during [lifecycle and health] meeting on 04 Feb 2026

7821fb2

SimonKozik had a problem deploying to workflow-approval February 4, 2026 13:06 — with GitHub Actions Failure

Conversation

SimonKozik commented Jan 29, 2026

Uh oh!

github-actions bot commented Jan 29, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

License Check Results

Uh oh!

github-actions bot commented Jan 29, 2026

Uh oh!

pawelrutkaq left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

pawelrutkaq Feb 3, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

SimonKozik commented Jan 30, 2026

Uh oh!

pawelrutkaq commented Jan 30, 2026

Uh oh!

SimonKozik commented Jan 30, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

github-actions bot commented Jan 29, 2026 •

edited

Loading

pawelrutkaq Feb 3, 2026 •

edited

Loading