Application SLA Description
On this page
Application Deployment SLA
The SLA deployment descriptor is a JSON file that describes the deployment of an application in the Oakestra platform.
An example SLA of application X
with two microservices X1
and X3
can be as follows.
Format
The file is composed of the following fields:
sla_version
: the current versioncustomerID
: id of the user, default is Admin- application list, in a single deployment descriptor it is possible to define multiple applications, each containing:
Fully qualified app name: A fully qualified name in Oakestra is composed of
application_name
: unique name representing the application (max 10 char, no symbols)application_namespace
: namespace of the app, used to reference different deployment of the same application. Examples of namespace name can bedefault
orproduction
ortest
(max 10 char, no symbols)applicationID
: leave it empty for new deployments, this is needed only to edit an existing deployment.
application_desc
: Short description of the applicationmicroservice list is a list of the microservices composing the application. For each microservice the user can specify:
microserviceID
: leave it empty for new deployments, this is needed only to edit an existing deployment.Fully qualified service name: Similar to applicattion name, it is composed of
microservice_name
: name of the service (max 10 char, no symbols)microservice_namespace
: namespace of the service, used to reference different deployment of the same service. Examples of namespace name can bedefault
orproduction
ortest
(max 10 char, no symbols)
virtualization
: Starting with 🪗 Accordionv0.4.301
, Oakestra supports bothcontainer
andunikernel
virtualizationcmd
: list of the commands to be executed inside the container at startupvcpu
: minimum cpu vcores needed to run the containervgpu
: minimum gpu vcores needed to run the containermemory
: minimum memory amount needed to run the containerstorage
: minimum storage size required (currently the scheduler does not take this value into account)bandwidth_in/out
: minimum required bandwith on the worker node. (currently the scheduler does not take this value into account)port
: port mapping for the container in the syntax hostport_1:containerport_1[/protocol];hostport_2:containerport_2[/protocol] (default protocol is tcp)addresses
: allows to specify a custom ip address to be used to balance the traffic across all the service instances.rr\_ip
: [optional filed] This field allows you to setup a custom Round Robin network address to reference all the instances belonging to this service. This address is going to be permanently bounded to the service. The address MUST be in the form10.30.x.y
and must not collide with any other Instance Address or Service IP in the system, otherwise an error will be returned. If you don’t specify a RR_ip and you don’t set this field, a new address will be generated by the system.
constraints
: array of constraints regarding the service.type
: constraint typedirect
: Send a deployment to a specific cluster and a specific list of eligible nodes. You can specify"node":"node1;node2;...;noden"
a list of node’s hostnames. These are the only eligible worker nodes."cluster":"cluster_name"
The name of the cluster where this service must be scheduled. E.g.: