feat: Allow tedge run all to run multiple mappers#4253
Conversation
Codecov Report❌ Patch coverage is 📢 Thoughts on this report? Let us know! 🚀 New features to boost your workflow:
|
Robot Results
|
tedge run all to run multiple mapperstedge run all to run multiple mappers
Bravo555
left a comment
There was a problem hiding this comment.
Ran aws and azure mappers without any issue. Very nice that we can run them all in parallel, in a single process! Nice work.
No Robot Framework test, but Rust-based tests seem complete and I guess setting up all the mappers for a Robot Framework test would be a bit annoying, so approving. (though still, I find even some token Robot Framework tests serve as some description of our supported public interface in the absence of more precise documentation)
rina23q
left a comment
There was a problem hiding this comment.
Great work. I tested the combination of tedge-mapper-local and tedge-mapper-c8y, it works as expected.
| /// this and leave crash recovery to the init system instead: the first unit | ||
| /// failure exits the process. | ||
| restart_on_crash: bool, | ||
| mode: SupervisorMode, |
There was a problem hiding this comment.
This kind of small improvement is always nice.
There was a problem hiding this comment.
Since this is a fairly major user-facing feature, some system test that starts multiple configured mappers with tedge run all, and the effect of SIGUSR1 that only restarts the mapper units and not the agent unit would have been nice (though there is sufficient unit test coverage). A simple combination like c8y and local would suffice.
|
|
||
| /// Returns all `MapperName`s whose cloud URL is configured in `tedge.toml`, | ||
| /// plus any user-defined mappers discovered under the `mappers/` directory | ||
| pub async fn configured_mappers(config: &TEdgeConfig) -> Vec<MapperName> { |
There was a problem hiding this comment.
The existence of a mapper directory with mapper.toml alone (even with the url field in it populated) doesn't always imply that the mapper is ready to be started, as it can be partially configured as well, right? So, don't we need some kind of marker to indicate if a given mapper is "enabled" or not? The user later might want to manually enable/disable a given mapper as well. Any plans to capture that "intent" into the config or as an external marker in the mapper directory?
There was a problem hiding this comment.
Possibly, but I think I would like to solve that more completely further down the line. We probably want to extend tedge run all to support all the long-running components at some point in the future, and I suspect that means we will require some way of defining what "services" should run under tedge run all. I think for now, just running all the mappers with some configuration is a reasonable default behaviour for now. As the interface isn't discoverable via the docs/cli help text, I'm considering this not to be a published API yet, so we can change this behaviour at a later stage anyway.
There was a problem hiding this comment.
Sure sure. I definitely didn't mean that for this PR. I was just curious to know what the plan is. This is definitely a good step forward.
fe47904 to
0c873c3
Compare
Signed-off-by: James Rhodes <jarhodes314@gmail.com>
Signed-off-by: James Rhodes <jarhodes314@gmail.com>
Signed-off-by: James Rhodes <jarhodes314@gmail.com>
0c873c3 to
8b996e1
Compare
I've now added a couple of tests to cover these |
Proposed changes
Extends the
tedge run allCLI to accept multiple arguments in order to run multiple mappers simultaneously, e.g.A bare
tedge run allcommand now runs all mappers defined in/etc/tedge/mappers.Types of changes
Paste Link to the issue
Checklist
just prepare-devonce)just formatas mentioned in CODING_GUIDELINESjust checkas mentioned in CODING_GUIDELINESFurther comments