Meta-issue: Re-organization of the rust code base using components

[didier-wenzek]

This is a meta-issue for tracking the progress of the re-organization of the rust code base using components.

The aim is to make the governance model effective with independent contributors implementing their own features with minimal conflicts.

Moving toward the updated vision for thin-edge and the envisioned architecture with Rust components that can be freely connected, will necessarily take time and poses risks. The proposal is to achieve this along clearly separated steps:

1. Preparation steps.
   • Remove pain points and major blockers toward homogeneous components.
   • Prepare step 2 with requirements and constraints on concrete IIoT needs.
   • Prepare step 4 to have this last step focused on interface refactoring and not internal.
2. Design the rust component API and runtime.
   • Define the interface for components to be freely combined into robust executables along well-defined type-safe combination patterns.
   • Different pieces of work have already been done in that direction and will be used as a source of inspiration. (see https://github.com/thin-edge/thin-edge.io/issues/1143 , https://github.com/thin-edge/thin-edge.io/pull/1036 , https://github.com/thin-edge/thin-edge.io/pull/979 , https://github.com/thin-edge/thin-edge.io/pull/1153 ).
3. Validate the rust component API on a small but representative thin-edge daemon.
   • The proposal is to work on the tedge_agent.
   • Iterate on and improve the API
   • Plan step 4
4. Refactor the rust code base of thin-edge using the validated rust component API.
   • Avoid user-visible changes at this stage.
5. Then in a position to implement the updated vision.

We will focus first only on the preparation steps: removing pain points and major blockers.

• [ ] #1404
• [ ] #1405
• [ ] Group Azure logic in a az_api crate
• [ ] #1410
• [ ] Group Software Management logic in a software_mngt crate
• [ ] #1406
• [ ] #1407

[TheNeikos]

To make sure no functionality is lost, can the current user-facing API be written down? I think it would be best to then freeze new features or to then keep updating the list.

This will help with scoping the amount of work required as well as make it easier to cross-check what has been ported and what not.

[didier-wenzek]

To make sure no functionality is lost, can the current user-facing API be written down? I think it would be best to then freeze new features or to then keep updating the list.

Good point. I will add this as well as a point about test coverage.

[TheNeikos]

Will the points themselves also be expanded?

For example "Remove pain points and major blockers toward homogeneous components." is not quite clear on what exactly needs to be done.

Is there also a timeframe? That way we know when we can start assisting or by when the move is expected to be done?

[didier-wenzek]

Will the points themselves also be expanded?

Sure. And your inputs are welcome.