Resource Manager

The aim of Resource Manager is to provide the interface for creating and managing compute, network and storage resources in BonFIRE infrastructure. Managed resources may physically reside at any BonFIRE testbed. The component is in charge of controlling the life-cycle of an experiment (http://doc.bonfire-project.eu/R3/reference/experiment-lifecycle.html and terminating the experiment when its ‘walltime’ expires. The Resource Manager provides its interface in form of REST API, which can be access in different ways, directly or programmatically through a CLI or a shell (restfully), through the portal using point and click or a higher level descriptions( in OVF or using the BonFIRE DSL (json) or a mix of the above). Currently the Resource Manager interface is used by any BonFIRE user agents, which includes Portal and Experiment Manager.

APIs provided

  • The API has an entry-point
GET / HTTP/1.1 Host: api.bonfire-project.eu
Accept: application/vnd.bonfire+xml
  • The API provides the list of active experiments for the currently logged in user. Use query parameters if you want to filter out results.
GET /experiments?offset={{offset}}&limit={{limit}}&sort_by={{sort_by}}&order={{ASC|DESC}} HTTP/1.1 Host: api.bonfire-project.eu
Accept: application/vnd.bonfire+xml
  • The API allows a user to create a new experiment container
POST /experiments HTTP/1.1 Host: api.bonfire-project.eu
Accept: application/vnd.bonfire+xml
Content-Type: application/vnd.bonfire+xml

<?xml version="1.0" encoding="UTF-8"?>
  <experiment xmlns="http://api.bonfire-project.eu/doc/schemas/occi">
  <name>My Experiment</name>
  <description>Experiment description</description>
  <walltime>7200</walltime>
  <groups>inria,whatever</groups>
  <aws_access_key_id>amazon access key id</aws_access_key_id>
  <aws_secret_access_key>amazon secret access key</aws_secret_access_key>
  <reservation>reservation id</reservation>
</experiment>
  • The API allows a user to fetch an experiment he owns
GET /experiments/{{experiment_id}} HTTP/1.1 Host: api.bonfire-project.eu
Accept: application/vnd.bonfire+xml
  • The API allows a user to delete an experiment she owns (experiment resources will be deleted in a near future, and the experiment status set to terminated):
DELETE /experiments/{{experiment_id}} HTTP/1.1 Host: api.bonfire-project.eu
Accept: */*
  • The API allows a user to add a compute resource to an experiment he owns (see the XML Schema Definition for the list of available elements in a compute description)
POST /experiments/{{experiment_id}}/computes HTTP/1.1 Host: api.bonfire-project.eu
Accept: application/vnd.bonfire+xml
Content-Type: application/vnd.bonfire+xml

<?xml version="1.0" encoding="UTF-8"?>
<compute xmlns="http://api.bonfire-project.eu/doc/schemas/occi">
  <name>Compute name</name>
  <description>Compute description</description>
  <instance_type>instance type</instance_type>
  <groups>somegroup</groups>
  <cluster>cluster id</cluster>
  <host>host</host>
  <disk>
    <storage href="storage id" />
    <type>disk type</type>
    <target>target</target>
  </disk>
  <nic>
    <network href="network id" />
    <device>device</device>
    <ip>ip</ip>
    <mac>mac</mac>
  </nic>
   <scheduling_id>scheduling_id</scheduling_id>
  <resource_set>myResourceSet</resource_set>
  <shared_allocation/>
  <best_effort_allocation/>
  <!-- This can contain any free-form element -->
  <context>
  </context>
  <link rel="location" href="/locations/{{location_id}}" />
</compute>

scheduling_id,resource_set, shared_allocation,best_effort_allocation are only used in the context of a reservation.

  • The API allows a user to update a compute resource of an experiment he owns:
PUT /locations/{{location_id}}/computes/{{resource_id}} HTTP/1.1 Host: api.bonfire-project.eu
Content-Type: application/vnd.bonfire+xml
Accept: application/vnd.bonfire+xml

<?xml version="1.0" encoding="UTF-8"?>
  <compute xmlns="http://api.bonfire-project.eu/doc/schemas/occi">
    <state>state of the vm</state>
    ...
  </compute>
  • The API allows a user to add a network resource to an experiment he owns (see XML Schema Definition for the list of available elements):
POST /experiments/{{experiment_id}}/networks HTTP/1.1 Host: api.bonfire-project.eu
Accept: application/vnd.bonfire+xml
Content-Type: application/vnd.bonfire+xml

<?xml version="1.0" encoding="UTF-8"?>
  <network xmlns="http://api.bonfire-project.eu/doc/schemas/occi">
    <name>Network name</name>
    <description>Network description</description>
    <groups>group1</groups>
    <!-- ><cidr>/24</cidr> //-->
    <size>C</size>
    <visibility>public</visibility>
    <!-- VW specific - must be a percentage between 0 and 1 -->
    <lossrate>0.5</lossrate>
    <!-- VW specific - milliseconds -->
    <latency>500</latency>
    <!-- VW specific - Mbps -->
    <bandwidth>1000</bandwidth>
    <!--> Below are tags needed by Federica<-->
    <network_link>
      <endpoint>
        <router href="router id"/>
        <router_interface>router interface</router_interface>
      </endpoint>
      <endpoint>
        <router href="router id"/>
        <router_interface>router interface</router_interface>
      </endpoint>
    </network_link>
    <network_link>
    </network_link>
  <link rel="location"         href="/locations/{{location_id}}" />
 </network>
  • The API allow a user to add a storage resource to an experiment he owns (see XML Schema Definition for the list of available elements):
POST /experiments/{{experiment_id}}/storages HTTP/1.1 Host: api.bonfire-project.eu
Accept: application/vnd.bonfire+xml
Content-Type: application/vnd.bonfire+xml

<?xml version="1.0" encoding="UTF-8"?>
  <storage xmlns="http://api.bonfire-project.eu/doc/schemas/occi">
    <name>Storage name</name>
    <description>Storage description</description>
    <groups>mygroup</groups>
    <type>type</type>
    <size>size</size>
    <fstype>file system type</fstype>
    <persistent>NO/YES</persistent>
    <public>NO/YES</public>
    <link rel="location"         href="/locations/{{location_id}}" />
  </storage>
  • The API must allow a user to delete a resource of an experiment he owns:
DELETE /locations/{{location_id}}/(computes|networks|storages)/{{resource_id}} HTTP/1.1 Host: api.bonfire-project.eu
Accept: */*
  • The API provides the list of participating testbeds
GET /locations HTTP/1.1 Host: api.bonfire-project.eu
Accept: application/vnd.bonfire+xml
Content-Type: application/vnd.bonfire+xml
  • The API allows a user to see a location.
GET /locations/{{location_id}} HTTP/1.1 Host: api.bonfire-project.eu
Accept: application/vnd.bonfire+xml
Content-Type: application/vnd.bonfire+xml
  • The API allows a user to fetch his profile:
GET /users/{{user_id}} HTTP/1.1 Host: api.bonfire-project.eu
Accept: application/vnd.bonfire+xml
  • The API provides a Reservation API (based on OAR):

To create a reservation, requests must be sent to the following URI: https://api.bonfire-project.eu/reservations with the following body:

<?xml version="1.0" encoding="UTF-8"?>
<reservation xmlns="http://api.bonfire-project.eu/doc/schemas/occi">
<group>myGroup</group>
<name>myReservation</name>
<description>optional description</description>
<walltime>P15H</walltime>
<starttime>2012-11-30T14:00:00Z</starttime>
<resources>
<!-- Resources to be filled in here - see later -->
</resources>
</reservation>

The resources can be instances (BonFIRE instance types) ,custom instances, hosts and cores.

Instances

<resources>
<instance>
<instance_type>lite</instance_type>
<location href="/locations/uk-epcc" />
<cluster>default</cluster>
<host>vmhost1</host>
<count>2<count/>
</instance>
</resources>

Notice that cluster and host are optionnal and can specify numbers rather than names.

Custom Instances

<resources>
<instance>
<instance_type>custom</instance_type>
<cpu>1</cpu>
<memory>1024</memory>
<location href="/locations/uk-epcc" />
<count>2<count/>
</instance>
</resources>

Here, the user must specify the cpu and memory.

Hosts

<resources>
<host>
<location href="/locations/fr-inria" />
<count>3<count/>
</host>
</resources>

To request the reservation of a complete physical host the user must specify the location and can optionally specify the cluster or the host.

Cores

<resources>
<core>
<location href="/locations/fr-inria" />
<count>3<count/>
</core>
</resources>

To request the reservation of a cores the user must specify the location and can optionally specify the cluster and the host.

Get informations related to a reservation

curl -kni https://api.bonfire-project.eu/reservations/xxxx

Delete a reservation

curl -kni https://api.bonfire-project.eu/reservations/xxxx -X DELETE

The RM also provides APIs to access Autobahn, Federica and Amazon. Please see the related sections in this documentation to get further details.

APIs used

RM, anything else

Message queue use

The API only write to the message queue. The description of the messages sent by the RM can be found on this page.

Assumptions

No documented assumptions

Implementation details

The RM is a Ruby On Rails application that uses an event-driven architecture in order to provide the API to the BonFIRE facilities. Experimenters can conduct experiments by issuing HTTP requests against the API. The Resource Manager API advertises the type of content it handles with the media type application/vnd.bonfire+xml. One of the most important component of the whole API is the LifecycleManager that is in charge of managing one experiment throughout its life. By default, it will regularly check the experiment status to see if there is an action to run. In some cases, if the manager knows when another action is supposed to happen, it will reschedule another check at a different time. The RM also uses a set of external libraries called “gems” in order to extend its capabilities. The Resource Manager maintains a database that keepings track of a user’s experiments and resources (network, storage, compute). The DB also stores the list of testbeds (locations) and the type of interface (occi_schema) they implement.

Database

The RM uses the following tables to work:

  • table events
Field Type Null Key Default Extra
id int(11) NO PRI NULL auto_increment
experiment_id int(11) YES MUL NULL  
kind varchar(255) YES   NULL  
status varchar(50) YES   NULL  
path varchar(255) YES   NULL  
timestamp datetime YES   NULL  
created_at datetime YES   NULL  
updated_at datetime YES   NULL  
  • table experiments
Field Type Null Key Default Extra
id int(11) NO PRI NULL auto_increment
name varchar(255) YES   NULL  
description text YES   NULL  
status varchar(50) YES MUL NULL  
walltime int(11) YES MUL NULL  
user_id varchar(255) YES MUL NULL  
locked_at int(11) YES   0  
created_at datetime YES   NULL  
updated_at datetime YES   NULL  
password varchar(255) YES   NULL  
routing_key varchar(255) YES   NULL  
aggregator_password varchar(255) YES   NULL  
groups varchar(255) YES MUL NULL  
aws_access_key_id varchar(255) YES   NULL  
aws_secret_access_key varchar(255) YES   NULL  
reservation varchar(255) YES   NULL  
slice_urn varchar(255) YES   NULL  
slice_user_urn varchar(255) YES   NULL  
slice_native varchar(255) YES   NULL  

This table contains the informations needed to manage the lifecycle of an experiment. The 3 last fields (those starting with slice) are used in the context of eco2cloud.

  • table locations
Field Type Null Key Default Extra
id int(11) NO PRI NULL auto_increment
name varchar(255) YES MUL NULL  
address varchar(255) YES   NULL  
latitude decimal(10,6) YES   NULL  
longitude decimal(10,6) YES   NULL  
url varchar(255) YES   NULL  
created_at datetime YES   NULL  
updated_at datetime YES   NULL  
occi_schema_id int(11) YES MUL NULL  
enabled tinyint(1) YES   1  
comment varchar(255) YES   NULL  

This table contains the locations of the different testbed. A location can be disabled by setting the enabled field to 0.

  • table occi_schemas
Field Type Null Key Default Extra
id int(11) NO PRI NULL auto_increment
name varchar(255) YES MUL NULL  
created_at datetime YES   NULL  
updated_at datetime YES   NULL  
  • table resources
Field Type Null Key Default Extra
id int(11) NO PRI NULL auto_increment
name varchar(255) YES   NULL  
description varchar(255) YES   NULL  
remote_id varchar(255) YES MUL NULL  
location_id varchar(255) YES MUL NULL  
experiment_id varchar(255) YES MUL NULL  
kind varchar(50) YES MUL NULL  
created_at datetime YES   NULL  
updated_at datetime YES   NULL  
user_id varchar(255) YES MUL NULL  
groups varchar(255) YES MUL NULL  
public varchar(255) YES   NO  

This table contains the reference to all the resources (ie compute, network, storage) that are used by all the experiments.

  • table schema_migrations
Field Type Null Key Default Extra
version varchar(255) NO PRI NULL  

This table contains the id of all the migrations that have been runned. A “rake db:migrate” command will not run a migration whose id is in this table.

  • table services
Field Type Null Key Default Extra
id int(11) NO PRI NULL auto_increment
location_id int(11) YES MUL NULL  
name varchar(255) YES MUL NULL  
ip varchar(255) YES   NULL  
created_at datetime YES   NULL  
updated_at datetime YES   NULL  

Below the descriptions of the 3 tables used by the RM in order to run the reservation system

  • table reservations
Field Type Null Key Default Extra
id int(11) NO PRI NULL auto_increment
reservation_id varchar(255) YES   NULL  
description text YES   NULL  
reservations text YES   NULL  
created_at datetime YES   NULL  
updated_at datetime YES   NULL  
compute varchar(255) YES   NULL  
inner varchar(255) YES   NULL  
expiration_date datetime YES   NULL  
groups varchar(255) YES   NULL  
user_id varchar(255) YES   NULL  

The reservations table records all the reservations We can see that there are 2 types of reservations, the main reservation is the one that you describde and launched, and the inner ones are those that are created by OAR each time a compute is created The main reservation can be seen as a kind of container that will contain the inners. You can see in this table, the link between a compute and a inner reservation.

  • table resourcesets
Field Type Null Key Default Extra
id int(11) NO PRI NULL auto_increment
reservation_id varchar(255) YES   NULL  
network_adress varchar(255) YES   NULL  
used varchar(255) YES   NULL  
available_blocs varchar(255) YES   NULL  
resource_set varchar(255) YES   NULL  
cluster varchar(255) YES   NULL  
allocation_units varchar(255) YES   NULL  

This table records the reservations that have been made using a resource set.

  • table resourcesetcomputes
Field Type Null Key Default Extra
id int(11) NO PRI NULL auto_increment
resource_set varchar(255) YES   NULL  
compute_id varchar(255) YES   NULL  
instance_type varchar(255) YES   NULL  
blocs varchar(255) YES   NULL  
shared_allocation tinyint(1) YES   1  

This table makes the link between a resource set and the computes that have been created using it The number of blocs is available, it decreases with computes creation and increases when a compute is destroyed (as well as a inner reservation of course).

The config file

This file, located in /config/options/defaults.yml, contains the different parameters used by the RM to work.

defaults: &defaults
  header_user_cn: X-Bonfire-Asserted-Id
  header_user_groups: X-Bonfire-Asserted-Groups
  header_experiment_id: X-Bonfire-Experiment-Id
  bonfire_occi_media_type: application/vnd.bonfire+xml
  bonfire_occi_namespace: http://api.bonfire-project.eu/doc/schemas/occi
  bonfire_uri: https://api.bonfire-project.eu:444/
  bonfire_monitor_name: BonFIRE-monitor
  # time in seconds between each run of the master lifecycle manager:
  bonfire_manager_interval: 5
  # time in seconds between each run of the lifecycle manager for a given experiment:
  lifecycle_interval: 60
  # time in seconds between the stopped notice and the shutdown of the resources:
  lifecycle_wait_before_shutdown: 300
  # time in seconds between the shutdown command and the deletion of the resources:
  lifecycle_wait_before_termination: 300
  # time in seconds before purging a terminated experiment:
  lifecycle_experiment_expiration_time: 3600
  # feature flags:
  # Enable support for groups
  flag_group_support: true
  # Destroy experiments when they're done and lifecycle_experiment_expiration_time has been hit.
  flag_destroy_experiments: false
  enactor_uri: http://127.0.0.1:8080/Enactor/webresources
  enactor_max_concurrency: 5
  # LDAP parameters
  ldap_host: 127.0.0.1
  ldap_port: 389
  ldap_base: dc=bonfire-project,dc=eu
  ldap_rootdn: cn=Manager,dc=bonfire-project,dc=eu
  ldap_rootpw: xxxxxxxx
  collections_cache_uri: http://localhost:8080/ccache/ccache/
  collections_cache_enabled: false
  # AMQP (Message Queue) parameters for openAccess
  amqp_host: 127.0.0.1
  amqp_port: 5672
  amqp_vhost: bonfire
  amqp_username: xxxxxxxx
  amqp_password: xxxxxxxx
  amqp_timeout: 10
  amqp_exchange: resourceUsage
  # AMQP (Message Queue) parameters for experiments
  expamqp_host: 127.0.0.1
  expamqp_port: 5672
  expamqp_vhost: bonfire
  expamqp_username: xxxxxxxx
  expamqp_password: xxxxxxxx
  expamqp_timeout: 10
  expamqp_exchange: experiments
  # oar
  oar_uri: http://oar.test.bonfire.grid5000.fr
  super_users_list: mygroup, onothergroup
  # Configuration for production machine:
  production:
    <<: *defaults
    # valid values are DEBUG, INFO, WARN, ERROR, UNKNOWN
    log_level: DEBUG
  # Configuration for development environment:
  development:
    <<: *defaults
    log_level: DEBUG
    enactor_uri: http://127.0.0.1:8081/Enactor/webresources
    bonfire_manager_interval: 5
    lifecycle_interval: 10
    lifecycle_wait_before_termination: 10
    lifecycle_experiment_expiration_time: 20
    ldap_port: 1389
    amqp_port: 15672
    oar_uri: http://oar.test.bonfire.grid5000.fr
  test:
    <<: *defaults
    log_level: DEBUG
    ldap_rootdn: cn=Manager,dc=bonfire-project,dc=eu
    ldap_rootpw: xxxxxxxx
    ldap_port: 1389
    amqp_port: 15672
    lifecycle_interval: 10

Notice that people whose group is listed after the super_users_list tag, will be able to list, get informations and delete all the reservations, even those that not belong to them.

The Gems:

In order to work, the RM needs dependencies that are listed in the Gemfile file that can be found in the root repertory of the RM.

1 source 'http://rubygems.org'
 2
 3 gem 'rake', '~> 0.8.7'
 4 gem 'rails', '~> 3.0.9'
 5 gem 'rack-fiber_pool'#, '~> 0.9'
 6 gem 'eventmachine', '~> 0.12.10'
 7 gem 'em-synchrony', '~> 0.2'
 8 gem 'em-http-request', '~> 0.3'
 9 gem 'addressable', '~> 2.2'
10 gem 'thin', '~> 1.5.0'
11 gem 'libxml-ruby', '~> 1.1'
12 gem 'state_machine', '~> 0.10'
13 gem 'amqp', "0.8.0.rc14"
14
15 gem "mysql2", "~>0.2.0"
16
17 # net-ldap v0.2.x raises a segmentation fault on CentOS. Sticking to v0.1.x.
18 gem 'net-ldap', '~> 0.1.0'
19 gem 'rdf'
20 gem 'rdf-xsd'
21
22 group :test do
23   gem 'webmock'
24   gem 'rspec'
25   gem 'rspec-rails', '~> 2.5'
26   gem 'autotest'
27   gem 'autotest-growl'
28   gem 'factory_girl_rails', '~> 1.0.1'
29   gem 'simplecov'
30   gem 'simplecov-rcov'
31   gem 'ci_reporter'
32   gem 'json', '~> 1.7.7'
33   gem 'yard'
34   gem 'bluecloth'
35   gem 'syntax'
36   # http://railroady.prestonlee.com/
37   gem 'railroady'
38   # required for drawing state diagrams:
39   gem 'ruby-graphviz', :require => 'graphviz'
40 end
Notice that the specifier ~> has a special meaning:
  • ~> 2.5 means >= 2.5 and < 3
  • ~> 0.12.10 means >= 0.12.10 and < 0.13
  • without this specifier, the latest version of a gem is installed (as well as the dependencies needed by the gem itself)

Table Of Contents

Previous topic

Experiment Manager

Next topic

Enactor Core

This Page