Feature/load new lifecycle config#208
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 |
| module_name = "score_baselibs", | ||
| commit = "498a4b256c9073602140243d30c33b106e279f75", | ||
| remote = "https://github.com/eclipse-score/baselibs.git", | ||
| ) |
There was a problem hiding this comment.
@paulquiring Any idea when a new baselibs release will be available containing the new flatbuffer functionality?
There was a problem hiding this comment.
Next release of baselibs: planed on 21.05 or 22.05. See https://github.com/orgs/eclipse-score/discussions/2390?sort=new#discussioncomment-16987333
| { | ||
| Native = 0, | ||
| Reporting = 1, | ||
| ReportingAndSupervised = 2, |
There was a problem hiding this comment.
Would just Supervised be sufficient? I guess Supervised applications have to be reporting or else they cannot be supervised?
| Terminated = 1 | ||
| }; | ||
|
|
||
| struct ComponentAliveSupervision |
There was a problem hiding this comment.
All struct members are default initialized to 0. I think to have some default values here which make sense could be helpful.
This applies also to all other configuration structs.
|
|
||
| } // namespace score::launch_manager::config | ||
|
|
||
| #endif |
There was a problem hiding this comment.
| #endif | |
| #endif // CONFIG_HPP |
| /// | ||
| /// @note As of now, everything is expected in a single config file. | ||
| /// Even though some fields appear as optional in the json schema, they are only optional if the configuration would be | ||
| /// split across multiple files. As only a single file is supported, the single config will contain all fields. |
There was a problem hiding this comment.
"Even though some fields appear as optional in the json schema, they are only optional if the configuration would be split across multiple files"
That is strange, why splitting configuration into more then one file influencing what optional means?
I would expect that everything which is std::optional in config.hpp simply does not need to configured.
| { | ||
| return fallback_run_target_; | ||
| } | ||
| const AliveSupervisionConfig& alive_supervision() const |
There was a problem hiding this comment.
it's quite a mix of styles.
setRunTargets and fallback_run_target, just one will do the job.
| } | ||
|
|
||
| private: | ||
| friend class Builder; |
There was a problem hiding this comment.
A comment would have been helpful to mention that this saves the need to write getters in the builder class.
| /// @note As of now, everything is expected in a single config file. | ||
| /// Even though some fields appear as optional in the json schema, they are only optional if the configuration would be | ||
| /// split across multiple files. As only a single file is supported, the single config will contain all fields. | ||
| class Config |
There was a problem hiding this comment.
It should be also possible to implement the Config member functions in the config.cpp file.
| std::vector<std::string> result; | ||
| if (vec != nullptr) | ||
| { | ||
| result.reserve(vec->size()); |
There was a problem hiding this comment.
I'm happy to see this line.
| { | ||
| if (ev != nullptr && ev->key() != nullptr) | ||
| { | ||
| result.emplace(ev->key()->str(), safeString(ev->value())); |
There was a problem hiding this comment.
I guess the key cannot be nullptr?
|
|
||
| SwitchRunTargetAction convertRequiredSwitchRunTargetAction(const fb::SwitchRunTargetAction* sa) | ||
| { | ||
| return convertSwitchRunTargetAction(sa).value(); |
| module_name = "score_baselibs", | ||
| commit = "498a4b256c9073602140243d30c33b106e279f75", | ||
| remote = "https://github.com/eclipse-score/baselibs.git", | ||
| ) |
There was a problem hiding this comment.
Next release of baselibs: planed on 21.05 or 22.05. See https://github.com/orgs/eclipse-score/discussions/2390?sort=new#discussioncomment-16987333
| constexpr int32_t kExpectedSchemaVersion = 1; | ||
| constexpr double kSecondsToMilliseconds = 1000.0; | ||
|
|
||
| uint32_t secondsToMs(double seconds) |
There was a problem hiding this comment.
#include <iostream>
#include <cstdint>
#include <string_view>
#include <cassert>
constexpr double kSecondsToMilliseconds = 1000.0;
uint32_t secondsToMs(double seconds)
{
return static_cast<uint32_t>(seconds * kSecondsToMilliseconds);
}
int main () {
assert(secondsToMs(0.000500) == 0);// holds is this a problem ?
assert(secondsToMs(0.001000) == 1);
}if this is a problem we might need to change the fbs

Note: The code is not actually in use yet. The python script which does the translation from the user-facing json configuration to the flatbuffer json format is not part of the PR and will be added in a follow up PR.
Furthermore, the launch manager code needs to be adapted to use the new structure.
Background:
Relates To: #209