Merge branch 'develop' of git://github.com/dana-i2cat/opennaas into develop
Merge branch 'develop' of git://github.com/dana-i2cat/opennaas into develop
Changed declared package to correct one.
Add BlueprinContainer for BoDRepository
Merge pull request #112 from jordi-puig/task/add-blueprint-bod-test

Task/add blueprint bod test
Merge branch 'develop' of git://github.com/dana-i2cat/opennaas into develop
Add l2bod blueprint to bod test
Merge pull request #114 from jordi-puig/task/add-blueprint-bod-test

Task/add blueprint bod test
Merge pull request #111 from isartcanyameres/fix/declare-correct-package-name

Fix/declare correct package name
Change RootLogger to debug level
Merge pull request #115 from jordi-puig/bug/gave-up-problem

Bug/gave up problem
Remove dependencioes to unexistent bundles.
Removed unexistend dependencies from platform.
Remove dependencies to unexistend bundles in integration tests.
Remove unexistent bundles from dependencies management.
Merge pull request #116 from isartcanyameres/fix/remove-unexistend-dependencies

Fix/remove unexistent dependencies
autobahn: Add first revision of Autobahn driver

This patch adds support for requesting and shutting down
connections via the Autobahn BoD.

This initial version hardcodes most connection parameters due
to lack of support for such parameters in OpenNaaS (bandwidth,
vlan ID, lifetime, etc). Once OpenNaaS BoD support has been
extended, the driver can be extended too. Consider this driver
a use case to drive the OpenNaaS BoD support forward.

The initial version lacks support for queue transactions. This
is because the Autobahn webservice is stateless and does not
support explicit transaction demarcation. Poor man's
transaction support without isolation could be achieved
by rolling back the creation/release manually (by releasing
or recreating), although there is no guarantee that a released
resource can be rereserved (it may have been taken by other
reservations). Implementing this is not straightforward as
OpenNaaS lacks support for a queue context or some other
way of maintaining state accross actions that are part of the
same queue execution. Once such support is added the poor man's
transaction support can be implemented.

The Autobahn driver requires access to both the user access
point and adminstration webservice interfaces of Autobahn.
These are by default published on the same port, so the
protocol context URI is simply the base URI for both services.
Eg:

protocols:context bod:autobahn autobahn http://autobahn.example.org:8080/autobahn/

The driver will internally append "uap" or "adminstration" to
this URI.

Access to the administrative interface is required as it is
otherwise not possible to query the list of existing reservations.

Note that OpenNaaS provides no user interface for inspecting the
model of the BoD resource. You either have to know the network
interfaces of Autobahn (by using the Autobahn GUI) or you have
to inspect the OpenNaaS log files.

Note that the Autobahn reservation process is asynchronous. When
OpenNaaS executes the request action, the driver only submits a
reservation request. Setting up the reservation can possible take
minutes (in multidomain setups). Therefore the driver will create
a link in the resource's model for any reservation not in a
finished state. Autobahn does allow a callback to be registered,
but this requires that OpenNaaS implements a particular webservice
and that there is connectivity from Autobahn to OpenNaaS (no
firewall). In either case, OpenNaaS doesn't know about such
asynchronous changes, so even if we implemented the callback
interface, we wouldn't be able to react to reservation changes
outside the execution of a queue.

As mentioned above, a reservation is represented as a link in
the model. It is set on the source's linkedTo field. Note that
Autobahn supports creating multiple reservations between the
same two ports (interfaces): Each reservation can use a
different VLAN ID. Since an interface in OpenNaaS only has one
linkedTo field, such reservations cannot be represented in
OpenNaaS.

Note that the NSI protocol treats interfaces differently: NSI
uses the concept of a network service endpoint, and such an
endpoint incorporates the VLAN. Ie VLAN isn't a property in NSI.
Instead, if you have two interfaces A and B, and a VLAN range
of 1000-1002, then you have service endpoints A-1000, A-1001,
A-1002, B-1000, B-1001, B-1002 (or whatever naming scheme the
NSA chooses to implement). In that case you can indeed only
have one connection between two endpoints (which would be
interfaces in OpenNaaS). The problem here is that often one
cannot connect all endpoints, eg A-1000 and B-1001 are not
connectable (depends on the hardware, of course). My point is
that BoD systems are sufficiently different from each other
that it may become difficult to make a common abstraction
in OpenNaaS (or that it will require extensive configuration
info to map between OpenNaaS' representation and the
representation in the BoD system - something that would be
a pain to maintain).

Authentication in Autobahn is disabled by default and it not
supported by the initial revision of this driver.

Integration tests are missing. These will be added soon.
bod: Add VLAN ID, reservation period, and capacity parameters

The patch extends the OpenNaaS BoD subsystem with features
required to make it useable with Autobahn.

The Autobahn driver is updated to use the new features.

I added the Joda Time library as a dependency.
bod: Add CLI support for listing interfaces and links

The patch adds the l2bod:interfaces and l2bod:links commands
to list the interfaces and links registered in the model of a
BoD resource.
autobahn: Add transaction support

I found a solution to the problem of attaching cross-action
state during queue execution: A thread local variable holds
the log. As long as all actions on a queue are executed
from the same thread, this solution will work nicely.

Callouts to Autobahn are now performed by commands queued
for execution during confirm. In case of restore the commands
know how to undo what they did.

The pattern I follow here sort of replicates some of the
functionality of QueueManager: Queuing, execution and rollback
of commands is not unlike the queueing, execution and rollback
of actions done by QueueManager. I get the feeling that
the Action concept could be improved such that the execute and
undo actions could be part of the actions themselves, thus
avoiding the need to implement something like the Transaction
class in the driver.