In the following, the controllers developed for the FLUIDOS Node are described. To see the different objects, see Custom Resources part.
The Solver controller, tasked with reconciliation on the Solver
object, continuously monitors and manages its state to ensure alignment with the desired configuration. It follows the following steps:
- When there is a new Solver object, it firstly checks if the
Solver
has expired or failed (if so, it marks the Solver asTimed Out
). - It checks if the Solver has to find a candidate.
- If so, it starts to search a matching Peering Candidate if available.
- If some Peering Candidates are available, it selects one and book it.
- If no Peering Candidates are available, it starts the discovery process by creating a
Discovery
. - If the
findCandidate
status is solved, it means that a Peering Candidate has been found. Otherwise, it means that theSolver
has failed. - If in the
Solver
there is also aReserveAndBuy
phase, it starts the reservation process. Otherwise, it ends the process, the solver is already solved. - Firstly, it starts to get the
PeeringCandidate
from theSolver
object. Then, it forge the Partition starting from theSolver
selector. At this point, it creates aReservation
object. - If the
Reservation
is successfully fulfilled, it means that theSolver
has reserved and purchased the resources. Otherwise, it means that theSolver
has failed. - If in the
Solver
there is also aEnstablishPeering
phase, it starts the peering process (to be implemented). Otherwise, it ends the process.
The Discovery controller, tasked with reconciliation on the Discovery
object, continuously monitors and manages its state to ensure alignment with the desired configuration. It follows the following steps:
- When there is a new Discovery object, it firstly starts the discovery process by contacting the
Gateway
to discover flavours that fits theDiscovery
selector. - If no flavours are found, it means that the
Discovery
has failed. Otherwise, it refers to the firstPeeringCandidate
as the one that will be reserved (more complex logic should be implemented), while the other will be stored as not reserved. - It update the
Discovery
object with thePeeringCandidates
found. - The
Discovery
is solved, so it ends the process.
The Reservation controller, tasked with reconciliation on the Reservation
object, continuously monitors and manages its state to ensure alignment with the desired configuration. It follows the following steps:
- When there is a new
Reservation
object it checks if theReserve
flag is set. If so, it starts the Reserve process. - It retrieves the FlavourID from the
PeeringCandidate
of theReservation
object. With this information, it starts the reservation process through theGateway
. - If the reserve phase of the reservation is successful, it will create a
Transaction
object from the response received. Otherwise, theReservation
has failed. - If the
Reservation
has thePurchase
flag set, it starts the Purchase process. Otherwise, it ends the process because theReservation
has already succeeded. - Using the
Transaction
object from theReservation
, it starts the purchase process. - If the purchase phase is successfully fulfilled, it will update the status of the
Reservation
object and it will store the receivedContract
. Otherwise, theReservation
has failed.
The Allocation controller, tasked with reconciliation on the Allocation
object, continuously monitors and manages its state to ensure alignment with the desired configuration.
(To be implemented)
The Network controller, tasked with reconciliation on the Broker
object, continuously monitors and manages its state to ensure alignment with the desired configuration. A struct of type ClientBroker is used as an image of the Broker
. It follows the following steps:
- After a reconcile is triggered checks if the
Broker
object has been deleted. - If so it performs the cleaning of the BrokerClient structure to disconnect from the broker gracefully and returns.
- It checks if another BrokerClient with the same name already exists, if so updates the already existing BrokerClient.
- If the name does not match, it checks the address, if it matches raises an error and deletes the
Broker
. - If no ClientBroker with same address or same name is found, it creates a new BrokerClient with the
Broker
data.