Skip to content

fog05 Abstractions

Jump to bottom
Gabriele Baldoni edited this page Jun 24, 2019 · 2 revisions

fog05 Entity

Updated 31/07/2018

The abstraction used by fog∅5 to provision, manage and orchestrate applications, or network functions, is the entity. An fog∅5 entity is either an atomic entity, such as a Virtual Machine, a container, a Unikernel, a binary executable, or a Directed Acyclic Graph (DAG) of entities (see Figure 1). Where the set of atomic entities supported by fog∅5 can be extended through plugins. Entities and Atomic Entities have a FSM that defines the legal state transitions. These state machines are decipted below.

In the rest of the document I may use Entity and Atomic Entity without any distinction.

fog05 entity example

fog05 Entity FSM

Here some points to the Entity (graph of atomic entities or other entity) states in fog05.

fog05 entity FSM

Each Entity can have one of this six states:

  • UNDEFINED
  • DEFINED
  • CONFIGURED
  • RUNNING
  • PAUSED
  • SCALING

The means of the state is the same defined below for the atomic entities

fog05 Atomic Entity FSM

Here you can find the definion of each state for Atomic Entity (VM/unikernel/container/miscroservice/ros2/...) in fog05. The FSM can be seen as two subsets of state, the ones rapresenting the Atomic Entity it self and the ones rapreseting an instance of the atomic entity

fog05 atomic entity fsm

Each Entity can have 9 states (the marine green ones):

  • UNDEFINED
  • DEFINED
  • CONFIGURED (creation of an instance)
  • RUNNING
  • PAUSED
  • SCALING
  • MIGRATING
  • TAKING_OFF
  • LANDING

Let's see in detail these states

UNDEFINED

Each Entity start from an "UNDEFINED" state because initialy nothing as been defined. This is a bogus state just to represent the fact that the entity is not yet defined.

DEFINED

The definition can be made in several ways:

  • From file (JSON) using the CLI interface
  • By passing the manifest as a parameter to the api.entity.define() function as seen in the API

If you want to define an Entity then the manifest should containt information for each component of that entity

After the definition the Entity is in DEFINED state this means that if all constrains are supported the Entity can be instanciated in each node it was defined, this means that is available in the 'catalog'. Each Entity should have a human readable name and an UUID to be identifiable.

A Entity in the DEFINED state can be undefined by calling the api.entity.undefined() function so it return to the UNDEFINED state that means that the Atomic Entity simply not exist anymore, or it can be instanciated calling the api.entity.configure() function. The state transitions need to be implemented in the plugin for that type of atomic entity. The callbacks are also visible in the FSM.

CONFIGURED

After that the Atomic Entity is in the CONFIGURED state (for a microserice this means that all configuration is load, for a VM/Container can mean that the appropriate resource have been created and configured [eg. disk files, network bridge]). This mean that there is an istance for that particular Atomic Entity. A Atomic Entity in CONFIGURED state can come back to DEFINED if the api.entity.clean() function is called.

RUNNING

If the api.entity.start() function is called the instance of that particular Atomic Entity goes to the RUNNING state, if the Atomic Entity is a microservice should implement a onStart() callback to initiate properly (eg. memory instantiation ...), for a VM/Container this is more easy because the VM/Container simply start (eg. using libvirt or lxd api)

In the RUNNING the Atomic Entity is actualy running, there are some possible transitions, the Entity can come back to CONFIGURED if some api.entity.stop() function is called, an Atmoic Entity can also be paused this means that it will interrupt execution without being killed, so it can resume from the current state, or can be scaled.

MIGRATING

A different situation is the migration, beacause, at first the agent should check if destination system is capable to handle a new Atomic Entity (eg. memory, disk,network, accelerators constraints) then if the migration in possible there will be actually two instance of the same Atomic Entity instance running on two different systems, each instance as a different state, the source one is in TAKING_OFF state and after migration will be destroyed so that instance will not be available anymore, the destination one is in LANDING state and after the migration will be in RUNNING state, for VM and Container the actual migration is handled by the underlaying hypervisor (eg. KVM or LXD) for microservices they should implement two callbacks:

  • before_migration() -> in which the microservice save is state and give them to the framework
  • after_migration() -> called by the framework to restore the state

All these state transitions can be executed using the API or the CLI interface

The detailed information model can be found here:

Clone this wiki locally