New configuration schema for Launch Manager by SimonKozik · Pull Request #88 · eclipse-score/lifecycle

SimonKozik · 2026-02-20T11:39:35Z

This is first version of JSON schema intended for Launch Manager configuration.

This PR builds on information gathered in #54, so there should not be too many surprises there.

Make initial_run_target mandatory, to force users to explicitly specify system startup behavior. Remove recovery_action requirement from run_target type, as meaningful defaults are difficult to define and enforcement should occur outside the schema.

github-actions · 2026-02-20T11:40:19Z

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: 3b0280be-c630-4654-99b6-e35080ee6164
Computing main repo mapping: 
Computing main repo mapping: 
Computing main repo mapping: 
Computing main repo mapping: 
Computing main repo mapping: 
Computing main repo mapping: 
Computing main repo mapping: 
WARNING: For repository 'rules_python', the root module requires module version rules_python@1.4.1, but got rules_python@1.8.3 in the resolved dependency graph. Please update the version in your MODULE.bazel or set --check_direct_dependencies=off
WARNING: For repository 'rules_cc', the root module requires module version rules_cc@0.2.14, but got rules_cc@0.2.16 in the resolved dependency graph. Please update the version in your MODULE.bazel or set --check_direct_dependencies=off
WARNING: For repository 'aspect_rules_lint', the root module requires module version aspect_rules_lint@1.5.3, but got aspect_rules_lint@2.0.0 in the resolved dependency graph. Please update the version in your MODULE.bazel or set --check_direct_dependencies=off
WARNING: For repository 'download_utils', the root module requires module version download_utils@1.0.1, but got download_utils@1.2.2 in the resolved dependency graph. Please update the version in your MODULE.bazel or set --check_direct_dependencies=off
WARNING: For repository 'googletest', the root module requires module version googletest@1.17.0.bcr.1, but got googletest@1.17.0.bcr.2 in the resolved dependency graph. Please update the version in your MODULE.bazel or set --check_direct_dependencies=off
WARNING: For repository 'score_rust_policies', the root module requires module version score_rust_policies@0.0.3, but got score_rust_policies@0.0.5 in the resolved dependency graph. Please update the version in your MODULE.bazel or set --check_direct_dependencies=off
Computing main repo mapping: 
Loading: 
Loading: 0 packages loaded
Loading: 0 packages loaded
Loading: 0 packages loaded
    currently loading: 
Loading: 0 packages loaded
    currently loading: 
Loading: 0 packages loaded
    currently loading: 
Loading: 0 packages loaded
    currently loading: 
Analyzing: target //:license-check (1 packages loaded, 0 targets configured)
Analyzing: target //:license-check (1 packages loaded, 0 targets configured)

Analyzing: target //:license-check (33 packages loaded, 9 targets configured)

Analyzing: target //:license-check (74 packages loaded, 9 targets configured)

Analyzing: target //:license-check (86 packages loaded, 9 targets configured)

Analyzing: target //:license-check (134 packages loaded, 715 targets configured)

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

Analyzing: target //:license-check (152 packages loaded, 7758 targets configured)

Analyzing: target //:license-check (160 packages loaded, 7817 targets configured)

Analyzing: target //:license-check (160 packages loaded, 7817 targets configured)

Analyzing: target //:license-check (160 packages loaded, 7817 targets configured)

INFO: Analyzed target //:license-check (165 packages loaded, 9955 targets configured).
[1 / 1] no actions running
[13 / 16] JavaToolchainCompileClasses external/rules_java+/toolchains/platformclasspath_classes; 0s disk-cache, processwrapper-sandbox
[14 / 16] 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: 31.430s, Critical Path: 2.65s
INFO: 16 processes: 12 internal, 3 processwrapper-sandbox, 1 worker.
INFO: Build completed successfully, 16 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-02-20T11:42:20Z

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

pawelrutkaq · 2026-02-23T09:00:07Z

...nager_daemon/config/future_config_schema/draft_schema/types/component_properties.schema.json

+          "type": "object",
+          "description": "Defines the configuration parameters used for alive monitoring of the component.",
+          "properties": {
+            "reporting_cycle": {


i would encode unit in key like _ms or sth. But this will come from API so shall not be here really or ?

I would prefer to avoid having measurement units as part of the name.
In my experience this doesn't works well long term.

As part of configuration documentation, which will follow in another PR, we will explain that all time periods are defined in seconds. If somebody needs to have something smaller, they can use decimal point.

Just to illustrate:

Delay of 1h

"delay": 3600

Delay of 2 milliseconds

"delay": 0.002

Delay of 5 microseconds

"delay": 0.000005

This should scale well and age well IMHO

Still for me 3600 looks like 3.6 sec and 0.002 as broken config (for me, timeouts always default to ms, not s, and decimal points, additionally, is 0.00000004 valid or not ? ;) ) ;] Having to read documentation for everything makse things just sad

From the schema point of view it would be strange to hard code units in the name. Let's us imagine that we all agree that millisecond will be the way to go. Let's also assume that few years from now, somebody concludes that this is not precise enough and we should use nanoseconds. After all even POSIX is using nanoseconds (https://pubs.opengroup.org/onlinepubs/9799919799/basedefs/time.h.html).

At this point in time you will need to change name. If you specify time in seconds (as the SI system does: https://en.wikipedia.org/wiki/International_System_of_Units) then it is user decision on how precise they would like to be. If implementation (and hardware) can handle this, then there is no problem. Otherwise some rounding will need to happen.

Additionally you will need to have a specific naming convention to denote units in time, otherwise this will diverge over the time. Please consider following:

delay_ms

delayMilliseconds

delay_milliseconds

Governing this over time will become harder as configuration will grow.

However the point about the need to read documentation is valid. Unfortunately there is no perfect solution for this... JSON schema doesn't allow you to specify units of measurements out of the box. You can do this through JSON Schema Symbols, but we would need to assume that tooling used for validation, supports extension vocabulary. And I'm not sure we can make this assumption.

However we can update description to clearly state that configuration is in seconds. For example
"description": "Specifies the length of the time window (in seconds) used to assess incoming alive supervision reports."

We can also apply this for other measurement units we have.

I know, as said to me not that obvious but i am fine with explanation ;]

can we then at least add the unit to the description string

As promised above, description units are documented in this commit: 6218342

...nager_daemon/config/future_config_schema/draft_schema/types/component_properties.schema.json

ramceb · 2026-02-24T09:55:55Z

...nager_daemon/config/future_config_schema/draft_schema/types/component_properties.schema.json

+          "type": "object",
+          "description": "Defines the configuration parameters used for alive monitoring of the component.",
+          "properties": {
+            "reporting_cycle": {


can we then at least add the unit to the description string

...nager_daemon/config/future_config_schema/draft_schema/types/component_properties.schema.json

ramceb · 2026-02-24T13:53:19Z

src/launch_manager_daemon/config/future_config_schema/examples/example_conf.json

+            "deployment_config": {
+                "bin_dir" : "/opt/apps/dlt-daemon"
+            }


How do we deal with different deployment configs e.g. for linux and qnx?

I know that we were talking about this in the last review, but this is a bit harder to handle in the schema than it looks at first glance.

With current schema we should be able to create Linux specific configuration file and also QNX specific configuration file. If we accept this version as the alpha version of schema, we could proceed with API adaptation and we could have Run Target based LM soon.

As a next step we can have another story to work on differences between Linux and QNX configuration and see what adaptations to the schema we need.
Current version of the schema is already complicated and it would be beneficial to add additional functionality in stages.

Finger cross this is OK.

Fine with me for the first version as long as we have it on the radar for the next version :-) For the next version it's a must then as we will have deployments for different OSes.

ramceb · 2026-02-24T13:54:34Z

src/launch_manager_daemon/config/future_config_schema/scripts/bundle.py

@@ -0,0 +1,223 @@
+#!/usr/bin/env python3


I really would like to see some bazel rules for bundling the final schema instead of checking in the "published_schema".

I just confirmed with my colleagues, that bazel integration is already half way done and will be part of another PR.

This PR will introduce automatic way to create flat buffer configuration files. This automation will include step to validate configuration against LM schema.

Please note that the next PR will also bring API changes, so you could use Run Targets from the user side.

sounds good.

ramceb · 2026-02-24T13:56:25Z

src/launch_manager_daemon/config/future_config_schema/README.rst

+This project uses a **two-folder approach** for schema management:
+
+- ``draft_schema/`` - Multi-file schema structure for active development
+- ``published_schema/`` - Single-file schema for end-user consumption


as mentioned above. We shouldn't check in generated artifacts unless absolutely needed.

It is a difficult question IMHO.

On one hand the size and the degree of the complexity of this schema, just lend itself to a multi-file setup. I started with a single-file schema, but in the middle of development, after applying review comments, I just moved to multi-file setup. It is much easier to handle changes this way, especially if changes are significant.

On the other hand, consuming a multi-file schema is more complicated on the user side. I had comments form my colleagues saying that single-file is much easier for them to handle.

It is difficult to have a perfect solution, so I'm proposing this compromise. But as pretty much every compromise, it has some downsides. I think we have three possibilities here:

We stay with current solution (i.e. we develop with multi-file setup and publish a single file).

We develop and publish multi-file schema.

We develop and publish single-file schema.

Which way we should go?

Fine if we stay with the current solution. I simply wouldn't check-in the generated file. We can create it during the build. If we have something like a binary release/SDK release in the future the published file we be part of it.

Co-authored-by: ramceb <89037993+ramceb@users.noreply.github.com> Signed-off-by: SimonKozik <244535158+SimonKozik@users.noreply.github.com>

ramceb · 2026-02-25T15:24:12Z

Additional comment as discussed in the meeting today. Please avoid folder names like draft_schema or future_config_schema. This is really confusing.

SimonKozik added 7 commits February 19, 2026 13:35

New configuration schema for Launch Manager

5ad60d0

Adding first version of documentation for json schema

415be1f

This schema is not yet in use, new folder name reflects this better

1989e86

New name should better reflect what is inside this folder

63e45bd

Improve development setup documentation

596a732

Adaptations to reflect changes in previous commit

346b7b5

SimonKozik temporarily deployed to workflow-approval February 20, 2026 11:39 — with GitHub Actions Inactive

Fixing copyright headers

75d558c

SimonKozik temporarily deployed to workflow-approval February 20, 2026 11:48 — with GitHub Actions Inactive

Changes introduced by 'bazel run //:format.fix'

31bb735

SimonKozik temporarily deployed to workflow-approval February 20, 2026 14:05 — with GitHub Actions Inactive

pawelrutkaq reviewed Feb 23, 2026

View reviewed changes

WilliamRoebuck mentioned this pull request Feb 24, 2026

Add config schemas for logging eclipse-score/baselibs#109

Open

ramceb requested changes Feb 24, 2026

View reviewed changes

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

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

SimonKozik temporarily deployed to workflow-approval February 24, 2026 16:00 — with GitHub Actions Inactive

SimonKozik and others added 3 commits February 24, 2026 16:50

Addressing review comment

6a82242

Co-authored-by: ramceb <89037993+ramceb@users.noreply.github.com> Signed-off-by: SimonKozik <244535158+SimonKozik@users.noreply.github.com>

Addressing review comments

57ef0eb

Co-authored-by: ramceb <89037993+ramceb@users.noreply.github.com> Signed-off-by: SimonKozik <244535158+SimonKozik@users.noreply.github.com>

Applying review suggestion

28cc1fc

Co-authored-by: ramceb <89037993+ramceb@users.noreply.github.com> Signed-off-by: SimonKozik <244535158+SimonKozik@users.noreply.github.com>

SimonKozik force-pushed the feature/new_configuration_schema branch from 976e8c9 to 28cc1fc Compare February 24, 2026 16:52

SimonKozik temporarily deployed to workflow-approval February 24, 2026 16:53 — with GitHub Actions Inactive

Adding measurements units to the description strings

6218342

SimonKozik temporarily deployed to workflow-approval February 25, 2026 17:31 — with GitHub Actions Inactive

Conversation

SimonKozik commented Feb 20, 2026

Uh oh!

github-actions bot commented Feb 20, 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 Feb 20, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

pawelrutkaq Feb 23, 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!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

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!

ramceb commented Feb 25, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

github-actions bot commented Feb 20, 2026 •

edited

Loading

pawelrutkaq Feb 23, 2026 •

edited

Loading