|Components||testbed database server, testbed node|
The inventory/catalogue must be kept updated with the new nodes, and nodes that are not longer available must be deleted.
We need to decide which mechanism we will use for the resource registration.
The database described in resource abstraction must be kept up to date to reflect the addition of nodes, their removal and changes to their configuration. It is desirable that the process requires minimal manual intervention and, if possible, that changes are reflected rapidly.
The testbed must keep a consistent behaviour under changes to the state of nodes, e.g. removing a CONFINE node or changing its configuration in a way that prevents a slice scheduled to it from running should trigger the rescheduling of the slice or its cancellation to avoid deploying it under insufficient or missing resources. Allowing CONFINE nodes to enter a maintenance state that explicitly excludes them from slice scheduling decisions may help keep consistency. Also, the database should be able to automatically update the state of unavailable CONFINE nodes to exclude them from slice scheduling (possibly triggering a notification to their admins); re-enabling the node need not be automatic.
The adequacy of the different approaches depends greatly on the nature and features of the CONFINE node database as described in resource abstraction.
In the case of a distributed database no registration is needed and the testbed node discovery process may yield different sets of nodes of changing characteristics. Manual intervention is minimal or nonexistent, but keeping a consistent behaviour may be difficult.
A database with complete coverage will need automatic update of non-CONFINE nodes, since it is unrealistic to expect community network users to manually update CONFINE testbeds databases. The implementation of this task should be network dependent, and it could rely on mechanisms provided by routing protocols such as BMX6 and OLSR.
In the case of a centralised or hybrid database, the following node registration options exist for CONFINE nodes:
Manual updates place the whole load on node administrators, but changes to this kind of node information are so rare that the required effort is not excessive; however it can also easily lead to outdated information if the node admin forgets to update it, which may end up in inconsistencies.
Automatic updates require some API for the exchange of node data between the server and the node, as well as some structured format for it.
One possible separation in hybrid updates is to centralise administrative node information and leave the other up to the node (or cache it). Thus the node admin only maintains the minimal information needed for the server and the node to get in contact and exchange the rest of information automatically.
Consistent with the use of a hybrid, caching database which periodically polls CONFINE nodes providing a structured resource description via HTTP (as suggested in resource abstraction), I suggest using hybrid updates, with the information residing at the central database being maintained manually while the information provided by the nodes is periodically retrieved and cached.
The retrieval of data from a CONFINE node can be used to automatically detect state changes from available to unavailable and vice versa, possibly with intermediate states to avoid instabilities.