hmon: Define configuration schema by eduard-moskalchuk · Pull Request #340 · eclipse-score/lifecycle

eduard-moskalchuk · 2026-07-21T15:08:45Z

No description provided.

github-actions · 2026-07-21T15:09:36Z

License Check Results

🚀 The license check job ran with the Bazel command:

bazel run --lockfile_mode=error //:license-check

Status: ⚠️ Needs Review

Click to expand output

[License Check Output]
Extracting Bazel installation...
Starting local Bazel server (8.6.0) and connecting to it...
INFO: Invocation ID: 0285cfa3-bab1-430e-95d8-57699d4d80a9
Computing main repo mapping: 
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: 
Analyzing: target //:license-check (1 packages loaded, 0 targets configured)
Analyzing: target //:license-check (1 packages loaded, 0 targets configured)

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

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

Analyzing: target //:license-check (140 packages loaded, 959 targets configured)

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

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

Analyzing: target //:license-check (163 packages loaded, 8245 targets configured)

Analyzing: target //:license-check (164 packages loaded, 8271 targets configured)

Analyzing: target //:license-check (164 packages loaded, 8271 targets configured)

Analyzing: target //:license-check (164 packages loaded, 8271 targets configured)

Analyzing: target //:license-check (168 packages loaded, 10283 targets configured)

INFO: Analyzed target //:license-check (169 packages loaded, 10409 targets configured).
[10 / 16] 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 ... (3 actions, 2 running)
[14 / 16] [Prepa] JavaToolchainCompileBootClasspath external/rules_java+/toolchains/platformclasspath.jar
[15 / 16] Building license.check.license_check.jar (); 0s disk-cache, multiplex-worker
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: 24.752s, Critical Path: 2.94s
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-07-21T15:20:51Z

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

arkjedrz · 2026-07-22T11:13:41Z

+}
+
+/// Thread parameters for the monitoring thread.
+table ThreadParameters {


What if certain parameters are optional?

Everything is optional unless explicitly marked as required, as I understand.

For scalar types flatbuffer will use a default value (e.g. 0) and you will not know whether it was actually configured or not.
If that is not suitable, you can use " = null;" to truly make it optional.

For non-scalar types you get nullptr from flatbuffer api in case it is not configured.

NicolasFussberger · 2026-07-23T07:53:04Z

+
+/// A time range with minimum and maximum durations in milliseconds.
+table TimeRange {
+  min_ms: uint32 (id:0);


I think you do not need to manually state these ids and can just remove them

NicolasFussberger · 2026-07-23T07:55:45Z

+  version_minor: uint32 = 0 (id:1);
+  supervisor_api_cycle_ms: uint32 (id:2);
+  internal_processing_cycle_ms: uint32 (id:3);
+  thread_parameters: ThreadParameters (id:4);


Not related to these changed, but I would be curious @eduard-moskalchuk if this thread configuration is working in your context.
I would assume in production environment application process will not have the privileges to changes the affinity or scheduling policy / priority for any of its threads.

Probably not. In QNX some secpol abilities would be required for that, and most applications don't have them.

NicolasFussberger · 2026-07-23T07:57:17Z

+/// Root configuration for a HealthMonitor instance.
+table HealthMonitorConfig {
+  version_major: uint32 = 1 (id:0);
+  version_minor: uint32 = 0 (id:1);


Probably we should align some versioning concept. In the launch manager config we only have a single schema version here

SimonKozik

It is difficult for me to comment on the LogicMonitor, StateNode, HeartbeatMonitor, DeadlineMonitor and DeadlineEntry definitions without seeing an example configuration.

I would appreciate if we could have an example configuration (for all possible configuration parameters), so we could better asses the schema.

SimonKozik · 2026-07-24T09:32:24Z

@@ -0,0 +1,180 @@
+{
+  "$schema": "http://json-schema.org/draft-07/schema#",


The LM schema is based on 2020-12 version. Maybe we can use newer version to keep this in sync?

SimonKozik · 2026-07-24T10:09:03Z

+    "schema_version": {
+      "type": "integer",
+      "minimum": 1,
+      "default": 1,
+      "description": "Schema version"
+    },


LM is using following construct:

"schema_version": { "type": "integer", "description": "Specifies the schema version number that the Launch Manager uses to determine how to parse and validate this configuration file.", "enum": [ 1 ] }

With your current proposal, integrator can configure 12 as schema_version and configuration will still pass validation.
Additionally I would be careful with using default in schema. They are not applied during validation and need to be added during configuration read. Populating not configured parameters with default values, during configuration load, is also a bit of a hassle.

I would suggest to go for enum here, and keep defined values always to a single number. Additionally I would define schema_version as required at the object level.
This way you will force integrator to declare which version of schema was used for configuration and if configuration validates against that schema, you will know that this schema can be used for reading this configuration file.

SimonKozik · 2026-07-24T10:09:43Z

+  "title": "HealthMonitorConfig",
+  "description": "Configuration schema for HealthMonitor (compatible with health_monitor_config.fbs)",
+  "type": "object",
+  "required": ["supervisor_api_cycle_ms", "internal_processing_cycle_ms"],


It may be worth to add schema_version here as well.

SimonKozik · 2026-07-24T10:33:19Z

+    "supervisor_api_cycle_ms": {
+      "type": "integer",
+      "minimum": 1,
+      "description": "Cycle duration in ms for supervisor API notifications"
+    },


LM is using seconds as the measurement unit of time (e.g., '0.5' for 500 milliseconds). I would be tempted to suggest that we should use the same approach for health monitoring.

This way integrator will be not restricted with precision they would like to use. Encoding precision in parameter name will force configuration change, when we would allow different precision.

Additionally it may be useful to define time as a reusable type. This type can be then used by supervisor_api_cycle, internal_processing_cycle and TimeRange

If we use floating point numbers, we may have to prove that we do it in a safe way. An activity that can be avoided. Please see the issue #345

SimonKozik · 2026-07-24T10:59:27Z

+    "SchedulerPolicy": {
+      "type": "string",
+      "enum": ["Other", "Fifo", "RoundRobin"],
+      "description": "Scheduler policy for the monitoring thread"
+    },


LM is using this construct to define scheduling policy:

"scheduling_policy": { "type": "string", "description": "Specifies the scheduling policy applied to the component's initial thread. Supported values correspond to OS-defined policies (e.g., FIFO, RR, OTHER).", "anyOf": [ { "enum": [ "SCHED_FIFO", "SCHED_RR", "SCHED_OTHER" ] }, { "type": "string" } ] }

This way you can get autocomplete, in some text editors, for POSIX defined schedulers, but you also allow configuration of OS specific schedulers.

Current version will restrict integrator to ["Other", "Fifo", "RoundRobin"] and force implementation to do translation from Fifo to SCHED_FIFO when reading config.

SimonKozik · 2026-07-24T11:04:43Z

+          "description": "Thread priority"
+        }
+      },
+      "required": ["policy", "priority"],


Are we sure that we would like to force integrator to always configure policy and priority? I would prefer to keep required configuration to bare minimum.

SimonKozik · 2026-07-24T11:15:45Z

+      "required": ["policy", "priority"],
+      "additionalProperties": false
+    },
+    "ThreadParameters": {


I would suggest to merge SchedulerPolicy, SchedulerParameters and ThreadParameters into a single type.

I'm not sure if I see benefits of keeping SchedulerPolicy and SchedulerParameters as a separate type.

github-project-automation Bot added this to LCM - Lifecycle & Health FT Jul 21, 2026

github-project-automation Bot moved this to Backlog in LCM - Lifecycle & Health FT Jul 21, 2026

eduard-moskalchuk requested a deployment to workflow-approval July 21, 2026 15:08 — with GitHub Actions Waiting

eduard-moskalchuk marked this pull request as draft July 21, 2026 15:09

anmittag assigned eduard-moskalchuk Jul 22, 2026

arkjedrz reviewed Jul 22, 2026

View reviewed changes

Comment thread score/health_monitor/src/cpp/health_monitor_loader.h Outdated

arkjedrz reviewed Jul 22, 2026

View reviewed changes

eduard-moskalchuk force-pushed the edmo_health_monitor_config branch from 8c18416 to 7863fe8 Compare July 22, 2026 15:07

eduard-moskalchuk requested a deployment to workflow-approval July 22, 2026 15:07 — with GitHub Actions Waiting

eduard-moskalchuk force-pushed the edmo_health_monitor_config branch from 7863fe8 to 032724b Compare July 23, 2026 06:56

eduard-moskalchuk requested a deployment to workflow-approval July 23, 2026 06:56 — with GitHub Actions Waiting

eduard-moskalchuk changed the title ~~hmon: Define configuration schema and Loader C++ API~~ hmon: Define configuration schema Jul 23, 2026

NicolasFussberger reviewed Jul 23, 2026

View reviewed changes

hmon: Define configuration schema

4cb138a

eduard-moskalchuk force-pushed the edmo_health_monitor_config branch from 032724b to 4cb138a Compare July 24, 2026 07:50

eduard-moskalchuk requested a deployment to workflow-approval July 24, 2026 07:50 — with GitHub Actions Waiting

SimonKozik reviewed Jul 24, 2026

View reviewed changes

		@@ -0,0 +1,180 @@
		{
		"$schema": "http://json-schema.org/draft-07/schema#",

Uh oh!

Conversation

eduard-moskalchuk commented Jul 21, 2026

Uh oh!

github-actions Bot commented Jul 21, 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 Jul 21, 2026

Uh oh!

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!

NicolasFussberger Jul 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!

SimonKozik 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!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

github-actions Bot commented Jul 21, 2026 •

edited

Loading

NicolasFussberger Jul 23, 2026 •

edited

Loading