Migration Guide [v4 to v5] plans #104
Description
Since backward compatibility can't be ensured, it has been decided on the RoadMap meetings, that a migration guide document has to be published in order to support the community in the transition.
Below you can find a proposal from AITIA for the skeleton of such document.
General
- No mandatory core systems, only recommended and support systems
- naming changes (mandatory core -> core; supporting core -> supporting)
- Naming convention
- Independent databases (No database ID is used to referencing)
- Unique system, service and device names within a Local Cloud
- Systems and services can be referenced in the Local Cloud, before they would be registered into the ServiceRegistry
- Authentication possibilities
- Ways of getting identity
- Ways of providing identity info (interface specific)
- Certificate profile changes
ServiceRegistry
- Service and operation representation
- Service instance identifier is generated from its properties
- One endpoint is one operation
- Interface representation
- System address is not the service access address
- Simple number versioning to semantic versioning
- String-String metadata -> String-Object metadata
SystemRegistry
- Merged into ServiceRegistry
DeviceRegistry
- Merged into ServiceRegistry
Authorization
- Authorization -> ConsumerAuthorization
- Peer to peer authorization rules -> policy based authorization
- Provider is able to define its own rules (MGMT level overrides it)
- Different rules for operations and events
- Policy instance identifier is generated from its properties
- Management endpoints are not only for the System Operator, but everyone with proper priviliges.
- Multiple type of authorizaion token (simple usage based, simple time limited and self contained)
Orchestrator
- Orchestrator -> DynamicServiceOrchestration, SimpleStoreServiceOrchestration, FlexibleStoreServiceOrchestration (one strategy per system)
- Orchestration flag changes
- Pull orchestration -> Pull and Push orchestration