Adding a new ready condition FileState - #402
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 |
FileState
| * **Description:** Specifies the required existence state of the file. | ||
| * **Allowed Values:** | ||
| * ``"Exists"``: The component is ready when the file at ``file_path`` exists. | ||
| * ``"Deleted"``: The component is ready when the file at ``file_path`` is deleted. |
There was a problem hiding this comment.
Are there any files which cannot be watched via inotify and thus we need to poll for their existence with some to-be-configured interval?
There was a problem hiding this comment.
As discussed only containers would be problematic here, and I think for now since we do not support containers anyways I don't think we should support this yet. I think in the future we could have an optional polling_rate var that when set would switch to using polling but don't think it makes sense to pay so much of a slow down to support a very specific scenario.
There was a problem hiding this comment.
I agree, support for polling only needs to be added if/when we support containers.
| { | ||
| ProcessState process_state{ProcessState::Running}; | ||
| std::optional<ProcessState> process_state{ProcessState::Running}; | ||
| std::optional<FileState> file_state; |
There was a problem hiding this comment.
I wonder if here or even in the user config we shall introduce some 'type' attribute that defines which type of ready condition is configured/used, or is it intended to support any combinations of these?
"readyCondition" : {
"type": "PROCESS_STATE",
....
}For now with just 2 types its probably still manageable as is.
If we introduce more ready conditions, it might get out of hand.
| // Absolute path to the file being watched. | ||
| file_path:string (required); // required | ||
| // Existence state of the file. Defaults to Exists if not specified. | ||
| state:FileExistenceState = Exists; // optional, defaults to Exists |
There was a problem hiding this comment.
Currently, all the default values are in scripts/config_mapping/lifecycle_config.py
I think this mapping is not existing in the PR
There was a problem hiding this comment.
6d1b659 to
90ddedb
Compare
| * **Description:** Specifies the required existence state of the file. | ||
| * **Allowed Values:** | ||
| * ``"Exists"``: The component is ready when the file at ``file_path`` exists. | ||
| * ``"Deleted"``: The component is ready when the file at ``file_path`` is deleted. |
There was a problem hiding this comment.
I agree, support for polling only needs to be added if/when we support containers.
| "Exists", | ||
| "Deleted" | ||
| ], | ||
| "pattern": "^/.*", |
There was a problem hiding this comment.
Looks like this validation was added to the wrong attribute?
If possible we should also test that the validation fails.
| case fb::FileExistenceState::Deleted: | ||
| return FileExistenceState::Deleted; | ||
| case fb::FileExistenceState::Exists: | ||
| default: |
| } | ||
| else if constexpr (std::is_same_v<argT, score::mw::launch_manager::configuration::FileState>) | ||
| { | ||
| SCORE_LANGUAGE_FUTURECPP_ASSERT_MESSAGE(false, "FileState is not yet supported"); |
There was a problem hiding this comment.
| SCORE_LANGUAGE_FUTURECPP_ASSERT_MESSAGE(false, "FileState is not yet supported"); | |
| SCORE_LANGUAGE_FUTURECPP_UNREACHABLE_MESSAGE("FileState is not yet supported"); |
053c31b to
9f99911
Compare
Adding a new ready condition for file state.
E.g. a component like "setup network" can wait for some
/dev/<network file>to make the component active. Then Later components can depend on this.