edgeless-project / edgeless

MVP Implementation
Other
16 stars 1 forks source link

Add a basic suite of ε-ORC unit tests #99

Closed ccicconetti closed 8 months ago

ccicconetti commented 9 months ago

Unit testing the resource required making the ResourceConfiguration API consistent with the others

raphaelhetzel commented 9 months ago

So, to explain the whole pattern of having nested APIs: The Agent/Orchestrator/Controller will(should) house more than one interface/API. As an example, the Agent currently provides the function instance API but should also provide the NodeStatusAPI and potentially the ResourceConfigurationAPI (which is essentially the "ResourceInstanceAPI").

Those APIs are all cloneable as the API is designed around the Rust Interface, and there might be multiple places/bindings where one might interact with a single instance of the runtime from multiple places (Example: a COAP and gRPC server need to interact with the same agent). That's also why they use the pattern where there is a lightweight cloneable client and a single non-cloneable task interacting using an MPSC channel. Slapping an Arc around the socket won't make this truly behave in that way. To achieve that, we either need to spawn up a second socket or somehow make the use of this one socket safe for use across multiple cloned copies. Similar to what I'm doing with the functions, we should factor out the generic thread-safety parts and introduce a trait to be implemented by each resource (in fact, there should be a resource trait (in the embedded crate), but we need a resource trait for normal nodes as well.

A ResourceProvider is similar to a function runtime, allowing functions to run and providing the ResourceConfigurationAPI. If you look at the runtimes, those only implement the FunctionInstanceAPI and not the Agent API.

Here, it would be interesting to see if we need more than one API from each resource provider, but I would suspect we only really need the ResourceConfigurationAPI (ResourceInstanceAPI) for each resource Provider.

We should move the multi-resource provider to the agent, let the agent provide the ResourceConfigurationAPI and ensure each ResourceProvider implements it in a cloneable and thread-safe manor (using the pattern described above).

ccicconetti commented 8 months ago

Rendered invalid by subsequent API refactoring