DECICE Framework Clause Samples

DECICE Framework. ‌ The DECICE framework favors a component based composition for its architectural approach, which enables switching between different implementations of the same component. Therefore, the plat- form can be specified and implemented as a set of interfaces that reflect the organizational structure of the project. Additionally, components interacting with external interfaces can be swapped out or updated if the external interfaces change without affecting the internal components. 1) it is still missing an elicitation and specification of requirements for the software architecture itself that is part of a future deliverable and will be published as soon as they have been defined. For the time being Figure 1 serves as a basis for understanding the minimal set of components that are required for the DECICE framework and what interfaces to other components they need to provide. Starting with the heart of the framework, the DECICE Control Manager is responsible for dealing with the majority of the business logic and is central to almost all control flows in the framework. In order to store settings, configuration and data relevant for the DECICE framework, the control manager has its own database, the DECICE Config Store. Another component the control manager might send requests to or receive from is the Platform Specific Glue Code for the wrapper as well as the scheduler. These interfaces serve as an integration of the control manager with the underlying platform. Here the compute plane is managed by Kubernetes but by swapping them out, they could also support another orchestration platform such as Hashicorp Nomad or Apache Mesos. The wrapper glue code serves as an abstraction for controlling the KubeAPI without having to internally adhere to its expected syntax and having the wrapper glue code translate requests from the internal representation to the format expected by the KubeAPI. The scheduler glue code serves as an entry point for the underlying platform to request scheduling decisions from the DECICE framework. The DECICE API exposes two components for interactions with the underlying platform, the end user API (job and telemetry) and the admin API (control and security). The end user API provides interfaces to submit jobs, deployments and workloads. These submissions are processed by the control manager and then stored to be considered during future scheduling decisions. Furthermore, it can also be used to send queries to the metrics storage, while conside...