Skip to content

Latest commit

 

History

History
60 lines (34 loc) · 3.85 KB

components.md

File metadata and controls

60 lines (34 loc) · 3.85 KB
Raw

Components

Let's see how each component has been implemented:

Local ResourceManager

The Local Resource Manager was constructed through the development of a Kubernetes controller. This controller serves the purpose of monitoring the internal resources of individual nodes within a FLUIDOS Node, representing a cluster. Subsequently, it generates a Flavour Custom Resource (CR) for each node and stores these CRs within the cluster for further management and utilization.

Available Resources

Available Resources component is a critical part of the FLUIDOS system responsible for managing and storing Flavours. It consists of two primary data structures:

  1. Free Flavours: This section is dedicated to storing Flavours, as defined in the REAR component.

  2. Reserved Flavours: In this section, objects or documents representing various resource allocations are stored, with each represented as a Flavour.

The primary function of Available Resources is to serve as a centralized repository for Flavours. When queried, it provides a list of these resources. Under the hood, Available Resources seamlessly integrates with Kubernetes' etcd, ensuring efficient storage and retrieval of data.

This component plays a crucial role in facilitating resource management within the FLUIDOS ecosystem, enabling efficient allocation and utilization of computing resources.

Discovery Manager

The Discovery Manager component within the FLUIDOS system serves as a critical part of the resource discovery process. It operates as a Kubernetes controller, continuously monitoring Discovery Custom Resources (CRs) generated by the Solver Controller.

The primary objectives of the Discovery Manager are as follows:

  • Populating Peering Candidates Table (Client): The Discovery Manager's primary responsibility is to populate the Peering Candidates table. It achieves this by identifying suitable resources known as "Flavours" based on the initial messages exchanged as part of the REAR protocol.

  • Discovery (Client): it initiates a LIST_FLAVOURS message, broadcasting it to all known list of FLUIDOS Nodes.

  • Offering Appropriate Flavours (Provider): In response to incoming requests, it will provide Flavours that best match the specific request.

Peering Candidates

The Peering Candidates component manages a dynamic list of nodes that are potentially suitable for establishing peering connections. This list is continuously updated by the Discovery Manager.

Under the hood, Peering Candidates are stored through an appropriate Custom Resource.

REAR Manager

The REAR Manager plays a pivotal role in orchestrating the service provisioning process. It receives a solving request, translates them into resource or service requests, and looks up external suitable resources:

  • If no Peering Candidates are found, it initiates the Discovery.
  • Optionally, if a suitable candidate is found, it triggers the Reservation phase.
  • If this process is successfully fulfilled, resources are allocated, contracts are stored, and optionally can start the Peering phase.

Contract Manager

The Contract Manager is in charge of managing the reserve and purchase of resources. It handles the negotiation and management of resource contracts between nodes:

  • When a suitable peering candidate is identified and a Reservation is forged, the Contract Manager initiates the Reserve phase by sending a RESERVE_FLAVOUR message.

  • Upon successful reservation of resources, it proceeds to the Purchase phase by sending a PURCHASE_FLAVOUR message. Following this, it stores the contract received.