Launch Manager supports the new configuration format#110
Conversation
License Check Results🚀 The license check job ran with the Bazel command: bazel run --lockfile_mode=error //:license-checkStatus: Click to expand output |
|
The created documentation from the pull request is available at: docu-html |
pawelrutkaq
left a comment
There was a problem hiding this comment.
The JSON files as test files are a bit bloat, maintaining them may be harsh. Maybe it would be better to have that in code and copose configs from well defined pieces.
nothing worrying, but next time it would be good to keep PR smaller.
| # | ||
| # SPDX-License-Identifier: Apache-2.0 | ||
| # ******************************************************************************* | ||
| exports_files(["s-core_launch_manager.schema.json"]) |
There was a problem hiding this comment.
lets remove s-core from name. makse no sens imho. and it even wors with - and _ mixup
There was a problem hiding this comment.
How about we move the renaming to the other open PR regarding configuration schema then it can directly be changed consistently everywhere
|
|
||
| ControlClient::ControlClient(std::function<void(const score::lcm::ExecutionErrorEvent&)> undefinedStateCallback) noexcept { | ||
| ControlClient::ControlClient() noexcept { | ||
| static std::function<void(const score::lcm::ExecutionErrorEvent&)> undefinedStateCallback = [](const score::lcm::ExecutionErrorEvent& event) {}; |
There was a problem hiding this comment.
why static fn and not simply lambda ?
There was a problem hiding this comment.
I guess lambda is equally fine. I can change it to lambda if you prefer that.
The idea here was merely to hardcode this callback to an empty callback for now to align the interface with the existing documentation.
After further discussion on how the API should look like, we can then either delete this or refactor.
examples/run_examples.bzl
Outdated
| # | ||
| # SPDX-License-Identifier: Apache-2.0 | ||
| # ******************************************************************************* | ||
| def _impl_run_examples(ctx): |
There was a problem hiding this comment.
why we just dont use sh_ or genrule ?
There was a problem hiding this comment.
Got rid of bzl file and replaced it with sh_binary
Regarding the JSON files. I agree it will not scale well. Currently, there are only few basic tests, because this configuration mapping is only temporary and the next step will be to read in the new config directly from the C++ code. I would expect we do some fine tuning of the new configuration and once we are happy we change the C++ code and the python script and its tests will all be obsolete. |
|
@eelcoem branch need to be up to date |
Done |
|
QNX x86 build fails due to download timeout, however the qnx arm build was successful.
|
* Basic python setup for mapping script * Add latest example configuration * Merging of default values * Basic smoketest for defaults preprocessing * Start to map PHM configuration * Separate unit and integration tests * Document mapping decisions and initial known limitations * Copy dict only internally when merging defaults * Initial mapping of hm configuration * Treat StateManager supervision same as other supervisions * Fix time unit and some flatbuffer schema violations * basic Integration test for health configuration * Better nameing of env vars in unit test * Configs for health integration test * Start work * Almost done * Add validation and update sample configs * Add health test for empty config * Update Readme file with validation info * Continue config mapping script * Cleanup * Fix error in mapping script * Minor fixes * Cleanup * Prevent cyclic dependencies * First changes * Cleanup * Undo some changes * Undo some changes * Bazel command for lifecylce config gen * Undo more changes, fix out of range * Config generation working without pip dependency * More cleanup * Export jsonschema python dependency * Fix python formatting * Adapt expected output to file renaming * Make shortName required * Update Readme file with bazel interface * Move script to tests folder * Initial version of the new API * Remove flatbuffer script * Address reviewer comments * Adapt ControlClient implementation to new API * Update health config integration test * Fix merge error in MODULE.bazel * Adapt examples to use the bazel config generation * Start demo via bazel target * Merge different pip environments * Add some custom validation rules * Migrate smoketest to new configuration * More integration tests * Revert debugging changes * Fix example scenario configuration * Correct smoketest configuration * Revert more debugging changes * Fix crash * Remove temporary schema file * Update readme file * Clarify that certain attributes will be ignored * Use lowercase name for watchdog * Run config tests via bazel * Define central lifecycle bazel rules * Add progress message to bazel function * Make pip environment a proper dependency This environment is used in the public bazel function for config generation * Improve error message * Remove obsolete config scripts * Fix formatting * Fix copyright headers * Tidy MODULE.bazel file * Improve schema validation error message * Fix formatting * Use defined default values in configuration mapping * Simplify bazel example runner --------- Co-authored-by: Empting Eelco (ETAS-ECM/XPC-Fe2) <Eelco.Empting2@etas.com> Co-authored-by: Eelco Empting <158553993+eelcoem@users.noreply.github.com> Co-authored-by: SimonKozik <244535158+SimonKozik@users.noreply.github.com> Co-authored-by: Paul Quiring <paul.quiring@etas.com>
Summary
This PR introduces a mapping of the new configuration schema to the existing configuration format. Therefore, allowing users to configure the launch_manager using the simpler configuration format. This approach is depicted here.
The configuration interface is a bazel function that validates the json configuration, maps the new configuration content to the existing configuration files that are in use by the C++ implementation. Note: This PR is not yet adapting the C++ code to load the new configuration directly, but instead it maps the new configuration to the old configuration format so the existing code keeps working as-is.
Usage Example from the reference_integration perspective:
Details
launch_manager_config, allowing users to easily make use of the new configurationlifecycle_config.py, taking as input the new configuration file and generating as output the same content in the existing configuration format (i.e. mapping of RunTarget -> ProcessGroup States). See the Readme at scripts/config_mapping/Readme.md for detailsCloses: #38