CARL does currently not persist any state. After a restart of CARL all resources (PeerDescriptor, ClusterConfiguration, ClusterDeployment, ...) are gone.

• [ ] determine which resources need to be persistent.
• [ ] select a suitable persistence architecture (relational, event sourced, document based, etc.).
• [ ] select a suitable DBMS.
• [ ] implement the required logic to persist resources.

EDGAR's setup command requires the confirmation from a user. This prevents the usage of the setup command in unattended environments like GH runner trying to setup peers for integration testing.

We could use the console crate's user_attended() function to check whether stdout is connected to a terminal instead of a file or redirected by other means and require confirmation in this state only.

To secure the system against unauthenticated access all components need to check the users identity and access privilege. For this purpose OpenID connect (OIDC) shall be used to authenticate users against a common identity provider - for which we use Keycloak. Each of our components shall therefore implement the OIDC protocol to ensure users are authenticated.

• [ ] implement OIDC client in LEA (public client with browser grant flow)
• [ ] implement OIDC client in CLEO/EDGAR (initially using a shared client secret)
• [ ] validate bearer tokens in CARL (using client secret)

For testing purposes the clients CLEO and EDGAR shall be able to craft access tokens with necessary authorization roles/scopes without contacting Keycloak. This crafted token shall not be checked in CARL when running in test mode.

We would like to have a plugin mechanism to extend openDuT with functionality for specific use-cases.

We plan to use WebAssembly as portable compilation target for plugins, but there's still various questions about the how.

Goals of the exploration:

• How do we exchange information (data) with plugins?
• Can we allow for everything we need past the sandboxing of WASM (e.g. FS access, root, network-interfaces/CAP_NET_ADMIN)? Are there meaningful usages of the sandboxing?
• How is the usability when developing plugins via Rust?
• Can plugins be developed via e.g. Python? How is usability there?
• Usage of plugins at least in EDGAR Setup.

References:

• General tutorial
• Transferring complex data types between WASM and Rust
• Interfacing with the OS
• Maybe a solution

To improve the user experience of CLEO (mostly in failure situations) a '--verbose' flag could provide more information to a user and help to solve the problem faster.

This story is about the Test-Manager (TM) component that represents the central application in openDuT to create new test projects, connect DuTs with specific test cases, schedule/ execute test runs and generate test reports.

Following features are to be integrated in a first step:

• [ ] Import and parsing of test cases provided in different formats (DSL, yaml, Robo Framework etc.) - consolidate solutions between ETAS and AVL
• [ ] TM receives a representation of the DuTs provided by EDGAR and CARL (e.g., available interfaces, other I/O, power supply) and thereby makes DuTs usable in TM
• [ ] TM communicates with EDGARs via VPN provided by CARL for - Receiving test results that were executed locally (cf. #5) - Provision of test engines (containers) to EDGAR for local execution - Provision of test setups/configuration to EDGAR for preparing local test setup (rest bus simulation, power control, clamps etc.)
• [ ] Execution, scheduling/planning and control of new test runs based on parsed test case (description) - consolidate solutions between ETAS and AVL - Case 1 (prio): Tests are executed locally on EDGAR - consolidation of test results and reporting by TM - Case 2: Tests are executed centrally by TM and test messages/ data is relayed to EDGAR, TM generates report - Case 3: Integration of external/remote test engines with openDuT (SaaS)
• [ ] Implement a user management on TM with RBAC (test engineers, project managers, auditors etc.)