User Tools

Site Tools


requirements:resource-abstraction

Resource abstraction

Code SRRM-2
Responsible Ivan Vilata
Components testbed database server, testbed node

Description

Resources available on the tesbed must be described and their information needs to be available on an inventory/catalogue.

Comments

This includes both CONFINE nodes as well as community nodes, but the information gathered from each equipment might be different.

Analysis

Details

There must be a database which describes, for each CONFINE node, at least the information which is relevant for testbed administration and management as well as for supporting resource allocation in combination with resource status information. Thus the database must describe the node and its resources but not their state, whose collection and publication is part of resource monitoring. The description should include a node identifier, a URL pointing to the node's community network info page, an administrative contact, a control IP address, an authentication token, node location, and resources available for experiments: memory and disk size, CPU speed and number, and network interfaces. Resources should be marked as shareable among slices or exclusive.

The particular set of items depends on the types of experiments supported. In any case, this information is mostly static and it rarely changes. In case there are changes to the node, the database should be kept up to date (see resource registration).

Solutions

Community networks (CNs) use to have their own databases describing their nodes. However, the set of information and the way it is represented varies greatly among them. This may justify adopting our own tool (new or existing) for uniformity inside and among CONFINE testbeds. There is a Open Networks Interoperability project which is working on defining a common schema (the common node database or CNDB) which may be leveraged by CONFINE.

Location options:

  1. Centralised, the database server keeps all information.
  2. Distributed, every node provides its own information. However, the database or testbed server should keep at least authentication tokens (maybe common like an SSH key or X.509 certificate).
  3. Hybrid, some data (e.g. list of nodes, node IP, admin contact, auth token) is kept in the database server while other (e.g. info page URL, resource description) is provided by nodes.

Node coverage option:

  1. Complete coverage, all nodes in the CN are represented in the database.
  2. Testbed coverage, only nodes in the testbed are represented in the database.

Accessibility options:

  1. Data is publicly available.
  2. Access to data is restricted.

A centralised database offers a simpler access to the information, but it needs a heavier registration and maintenance process. A distributed one may not need registration but it may need a non-trivial testbed node discovery process. A hybrid database may simplify maintenance but it would require a resource description API in nodes; if this information is cached, it can also act as a centralised database.

In a database offering complete coverage, the information available for normal CN nodes may differ substantially from that of CONFINE nodes and among different CNs. Normal CN nodes or database servers should also export this information via an API, a requirement which may be difficult to accomplish. In exchange, this may allow the testbed to have a full picture of the network (e.g. topology). With only testbed coverage there is full control over the provided information, but the testbed lacks a full picture of the network.

Public access to data may enable unplanned, third-party experiments on nodes' data while not revealing security-sensitive information (as long as authentication tokens and maybe admin contacts are not published).

Recommendation

I recommend a hybrid database approach where resource description data is provided by CONFINE nodes as structured, text data publicly via HTTP, and periodically retrieved and cached by the database server. This should also help detecting changes in data and nodes automatically, useful for resource registration. When possible, the CNDB schema should be used as a reference for data storage.

Given the potential difficulty of having a complete network coverage, I suggest starting with testbed-only database coverage. Later we can try to collect and represent the topology of the whole network, hopefully (but not necessarily) storing also the URL of each normal node's CN info page. The implementation of this task should be CN-dependent.

requirements/resource-abstraction.txt · Last modified: 2012/02/02 13:59 by ivilata