The unit type identity doesn't have a VM name. SDV design allows defining ACL policies for unit types in any VM within the mesh. While this allows for extra flexibility, the design also assumes that ACL policies for the same unit type originating from different VMs won't conflict. If conflicting policies are set, the result is undefined.
Under most circumstances, the optimal solution is deploying RPC servers, Publishers and ACL policies in the same VM.
The following examples demonstrate scenarios where unexpected results can occur.
VM disconnected from mesh
Imagine that there are three VMs in the software-defined vehicle (SDV) mesh:
- The RPC client is deployed on VM A. We'll call this client Foo.
- The RPC server (service unit) and its ACL policy are deployed on VM B. We'll call this server Bar.
- The ACL policy for the RPC interface, which RPC server Bar implements, is deployed on VM C.
For example, if VM C is off due to low power mode, the RPC client won't be able to discover the RPC server and thus can't establish a connection.
If VM C is disconnected from the mesh (for example, low power mode, update, disconnection), then:
- The Bar can't register itself within the SDV communication strack as ACL policies for the RPC interface aren't available.
- The Foo can't reach the Bar even though the Bar ACL policy is available.
Inconsistent ACLs
Authorization decision describes how the authorization results are calculated when unit type ACLs come from multiple VMs.
If there are inconsistent (or different) ACLs for the same unit type deployed on multiple VMs, this might lead to inconsistent authorization results in the following cases:
- Connection between VMs is broken. When the connection is dropped, corresponding cached unit type ACLs are wiped.
- VMs are turning on and off. This leads to the connection drop.
We recommend keeping the unit type ACLs the same on different VMs.