-
Notifications
You must be signed in to change notification settings - Fork 8
09 Design Decisions
| Documentation |
|---|
| See description |
- not yet decidedA core aspect of the project is that each asset must have a gateway and exactly one gateway.
How relevant is this in situations where the manufacturer is capable of building in the required logic into the on-board modules?
TODO
+ decidedIndustry Fusion envisages running in cases where the factory owner does not wish to have his infrastructure in the cloud (for security or connectivity reasons).
Managing this infrastructure will require a number of services. A requirement is that the server OS provide OpenStack and Kubernetes to abstract the deployment of applications onto the server.
From https://www.starlingx.io/:
StarlingX is a complete cloud infrastructure software stack for the edge used by the most demanding applications in industrial IOT, telecom, video delivery and other ultra-low latency use cases. With deterministic low latency required by edge applications, and tools that make distributed edge manageable, StarlingX provides a container-based infrastructure for edge implementations in scalable solutions that is ready for production now.
In this case a custom linux OS will be build and deployed which provides OpenStack and Kubernetes.
Decision at the sprint meeting on 09.10.2019:
StarlingX will be used as the edge factory server OS pending a security review.
+ decidedOISP provides a number of components in a ready-built manner which greatly reduces the effort involved in contrast to selecting, tailoring and configuring the required services by hand. In addition certain components will have to be implemented.
OISP comprises:
- a Kafka instance
- an OpenTSDB instance
- an auth provider
- a southbound API
- a northbound API
- an alerting Engine based on Apache Flink
- a PostgresQL DB
- dashboards based on Grafana
Decision at the sprint meeting on 09.10.2019:
OISP will be used for the MVP and based on this re-evaluated for the 1.0 release.
+ decidedIn the IF architecture it is envisaged that the gateways after a discovery and onboarding be remotely managed by the factory server. There are a number of options for achieving the remote management:
There are a number of linux package management frameworks which are typically used to manage the local installation of packages on a linux server. The first generation (such as rpm, deb etc.) offer solely package installation with dependency management and a on-server database of installed packages. The second generation are offer more security features such as application isolation, sandboxing, permissions (some frameworks) etc.
The 3 most important frameworks are:
- Flatpak
- AppImage
- Snap
See a comparison here: https://github.com/AppImage/AppImageKit/wiki/Similar-projects#comparison
Advantage: less complex than Kubernetes.
Disadvantage: has typically no mechanisms for the distribution of apps.
Disadvantage: has typically no mechanisms for the central management of apps although presumably there are some OTS server side components that can be used to accomplish this?
Disadvantage: has typically no mechanisms for the distribution of application configuration.
Kubernetes was originally envisaged for the orchestration of containers across clusters of hosts, specifically for automating application deployment, scaling, and management. In the broadest sense this applies to the management of fleets of gateways from a master but this represents a special case.
Advantage: Kubernetes manages both application containers and the configuration of them.
Disadvantage: "Kubernetes is hard" is accepted across the industry.
Decision at the sprint meeting on 09.10.2019:
For the disadvantages detailed above for the alternatives K8S will be used for application management of the gateways.
+ decidedOption 1: Container OS such as CoreOS or RancherOS
Option 2: Custom Linux OS with K8S provider
A requirement is that it will run in a constrained environment which limits the choice to the following minimal K8S:
Option 1: K3S
Option 2: Kubeedge, Microk8s, others
Decision at the sprint meeting on 09.10.2019:
- We may need the flexibility of installing / adapting parts of the OS: this means we will use a custom linux OS based on a standard distribution.
- The K8S provider was chosen as K3S as it seems to be the most mature now.
Should K3S prove to be unsuitable we will revise this decision. Also open is whether K3S can manage mixed architecture clusters (X86 and ARM). This is a requirement as the likelihood is high that some gateways be ARM / RasPi based (i.e. Revolution PI).
+ decided (docker repository open)As it was decided to use OISP to cover a large section of required components for Fusion OS a large portion of this decision became superfluous. The remainder is illustrated in 04-Solution-Strategy (OISP and overall Architecture)
Key points from the linked diagram
- OISP and the Fusion web applications will be deployed to the StarlingX K8S
- The Fusion web applications will share the OISP DB instance
- The Fusion web applications will where required access the TS DB of OISP
- The K3S master including the gateway management server will be deployed as a VM with the OpenStack of StarlingX
- A docker repository is also deployed in a VM in OpenStack (TODO why not in K8S?). It is suggested to use Docker Registry and to avoid using it in proxy mode but rather explicitly deploy all used container images to it.
+ decidedIn order to maximize synergy and interchangeability of developers on all tasks it is suggested to standardize the application stack.
The following stack is suggested for all applications:
- Java 11 OpenJDK
- Spring Boot 2 (latest)
- Angular 8 / 9
- JS application served from Spring Boot
- Jib for the container of the java applications
- Maven
After a discussion and some prototyping the stack was adopted with some slight changes:
- Java 11 OpenJDK / AdoptJDK
- Spring Boot 2 (latest)
- Angular 8
- JS application served from NGINX
- Jib for the container of the java applications
- Maven
- not yet decidedNon-isolated VPNs spanning several sites to enable FW updates?
- not yet decided- Fixed
- Folder structure with metadata
- not yet decidedSee 09.1 Design Decisions - Gateway Runtime
+ Decided (see sub page)See 09.2-Design-Decisions-Deletion
| < 08 Concepts | ^ index | 10 Quality Scenarios > |
|---|
- Architecture
- Development
- Miscellaneous