The BtrPlace Constraints Catalog
Summary

Notations

This chapter describes the notations that are used in the catalog to depict configurations or constraints

Describing a configuration

A configuration depicts the state of servers and virtual machines (see Chapter  "Virtualized hosting platforms" ), and the current placement of virtual machines. For convenience, we propose here a textual, human readable, format to describe a configuration. Listing 1 describes the textual format for a configuration using the Extended Backus-Naur Form (EBNF) [19]. In addition, every identifier in a configuration is supposed to be unique.

configuration = server (endl+ server)* (endl+ waitings)? endl*;

on_id = id;

off_id = "(" id ")";

paused_id = "!" id

waitings = "?" ":" on_id+;

server = (server_off | server_on);

server_off = off_id;

server_on = on_id ":" vm*;

vm = on_id | off_id | paused_id;

endl = "\n";

letter = "a" ... "z" | "A" ... "Z";

digit = "0" ... "9";

id = letter (letter | digit)*;

Listing 1: EBNF definition of a configuration

Listing 2 depicts a sample configuration composed of 3 servers and 5 virtual machines. Server N1 and N2 are in the Online state. N1 is hosting 3 virtual machines that are VM1, VM2, and VM3. VM1 and VM2 are in the Running state while VM3 is in the Suspended state. The server N2 is hosting the virtual machine VM4 that is in the Paused state. The server N3 is in the Offline state. Finally, the virtual machine VM6 is in the Waiting state.

N1 : VM1 VM2 (VM3)

N2 : !VM4

(N3)

?  : VM6

Listing 2: A sample well-formed configuration.

Describing a constraint

Declaration

Each constraint presented in the catalog has a specific signature. In practice, a constraint has an unique identifier and takes into account a variable amount of parameters. Listing reflet: cstr decl ebnf describes the textual format for a constraint signature using the EBNF.

constraint_decl = id "(" params ");

id = letter (letter | digit | "_")*;

letter = "a" ... "z" | "A" ... "Z";

digit = "0" ... "9";

 

params = param ("," param) *;

param = id ":" type;

type = (VM_t | server_t | number_t | set_t | string_t);

VM_t = "VM";

server_t = "server";

number_t = "number";

string_t = "string";

set_t = "set<" type ">";

Listing 3: EBNF definition of a constraint signature

The following signature declares a constraint named foo, that takes as parameters a set of VMs named s1, a set of servers named s2, a number x, and a string y:

foo(s1:set<VM>, s2:set<set<server>>, x:number, y:string)

Usage

Constraints deserves to be used to indicate management restrictions. Listing 4 describes the textual format for a constraint call using the EBNF.

constraint_ref & id "(" params ");

params & param ("," param)*;

param & id | set | string;

set & { params? };

 

string & """ (letter | digit)* """;

id & letter (letter | digit | "_")*;

letter & "a" ... "z" | "A" ... "Z";

digit & "0" ... "9";

Listing 4: EBNF definition of a constraint signature

Following example shows a sample usage of the constraint foo declared previously. The first argument is a set of 3 elements named VM1,VM2,VM3. From the constraint signature, each of these elements has to be a virtual machine. The second parameter is a set of 2 servers that are named N1, and N2. The third parameter is the number 5. The fourth parameter is the string "bar" :

foo({VM1, VM2, VM3}, {{N1, N2},{N3}}, 5, "bar")