Feature request/configuration model #2353
Conversation
AThums
requested review from
FScholPer,
antonkri,
johannes-esr and
qor-lb
as code owners
|
|
There was a problem hiding this comment.
Feature request does not follow Process, needs to use https://github.com/eclipse-score/score/blob/main/.github/ISSUE_TEMPLATE/3-change.yml
Compare also https://eclipse-score.github.io/score/main/contribute/contribution_request/index.html
and especially
https://eclipse-score.github.io/score/main/platform_management_plan/change_management.html#doc__platform_change_management_plan
Issue #2357 following template created and linked |
masc2023
left a comment
masc2023
left a comment
There was a problem hiding this comment.
Linked the PR to the ISSUE, so that it follows the Process,now
|
The created documentation from the pull request is available at: docu-html |
AThums
force-pushed
the
feature_request/configuration_model
branch
from
bb207b2 to
7ecd3b2
Compare
issue linked |
|
re-opend to merge |
|
@ramceb : As we were also interested in this topic, can you please give feedback on the content. Thanks, Andreas |
ramceb
left a comment
ramceb
left a comment
There was a problem hiding this comment.
@AThums: Thanks for driving this. Content-wise this goes in the right direction. 5 cents from my side. Sorry for the loose collection of thoughts.
-
the configuration of applications shall be self-contained. This makes testing etc much easier as there are no implicit assumptions on the environment. e.g. an application shall desribe how it wants to be supervised.
-
applications shall describe their assumed and guaranteed capabilities. What they need from their enviroment and what they provide to the environment. Capabilities can be: secpol/selinux config, provided and required services, filesystem access, any other resources etc. out of this we can derive then dependencies.
-
the software platform shall take care at startup if it can fulfill the needs of an application or not.
-
any configuration parameter shall have a direct impact on the behavior of the platform.
-
if we have applications depending on each other, we shall assume that they are developed based on similar application framework, which shall provide consistency checking accross applications.
@ramceb considered point 1, 2, and 4. Point 3 is a requirements to platform module and 5 to the application module developer. Thanks for review and pls. request a committer to accept the feature request so that we can start working on the content. |
| Abstract | ||
| ======== | ||
|
|
||
| This proposal introduces a unified approach to static module configuration in S-CORE by combining a Configuration Guideline and a Configuration Model. While the guideline defines how configurations should be structured—covering naming conventions, identifier usage, storage formats, and parameter organization—the model specifies what needs to be configured, focusing on common elements that must remain consistent across all modules. The dual approach ensures clarity, predictability, and maintainability, reducing integration complexity and improving user experience. By standardizing both the structure and the content of configurations, the solution enables faster onboarding of new modules, supports future extensions (e.g., JSON or FlatBuffers), and lays the foundation for automated compliance checks. |
There was a problem hiding this comment.
Perhaps a more neutral term like "Platform Component Configuration" and "Application Configuration" would be better.
In the S-Core context, a "module" is understood as a container implemented through a repository with a BAZEL module.
|
|
||
| 2. **Migration Timeline**: Coordination with existing module development cycles | ||
|
|
||
| 3. **Validation Granularity**: Define scope of cross-module consistency checks vs. module autonomy |
There was a problem hiding this comment.
For better understanding, I would speak of local configuration vs. global configuration.
Even with a locally stored configuration, I would separate the local and global/cross-functional aspects.
This way, the global/cross-functional aspects can be better checked during integration.
| ========== | ||
|
|
||
| The current configuration landscape in S-CORE suffers from fragmentation: contributors define static configurations independently, leading to inconsistencies in identifiers, variable naming, and file storage. Beyond structural differences, there is no common understanding of what must be configured for each module (e.g. how to support for "multiple instances"). This results in missing or redundant parameters, unclear dependencies, and unpredictable integration behavior. Without a shared model, cross-module consistency can hardly be guaranteed, making maintenance and scaling difficult. Introducing both a guideline and a model addresses these gaps by ensuring uniformity in configuration structure and content, reducing errors, and improving overall system reliability. | ||
|
|
There was a problem hiding this comment.
It should be explained what the configuration object is.
- Application configuration (e.g. ADAS application)
- Middleware configuration (e.g. selection of functionality, adaptation to OS, HW, ...)
4 participants
Feature request for issue #2357 as discussed in https://github.com/orgs/eclipse-score/discussions/472#discussioncomment-14990332
Goals is to discuss and acceüt this feature request in F2F meeting in Jan