The software is released with a dual L-GPL/ASF licensing schema that ensures that the platform will remain open and consistent, while commercial derivatives can be built on top. This open schema allows trust to be built on the platform, as NRENs and commercial network operators can rely on the continuity, transparency and adaptability of the platform.
In some cases, it is necessary to add memory in order to compile OpenNaaS. Follow the instructions of this article in the maven project to know how to avoid the OutOfMemoryError.
Error cloning OpenNaaS git repository in Windows. error: unable to create file … (No such file or directory).
There is a path length limitation in mingw32, which is 260 characters:
mingw32 is used to emulate the git CLI on windows.
Currently, none of OpenNaaS files have paths longer that 260 characters, current maximum is 216. However, depending on the directory you are cloning the git repo to, some files will end up with a path longer than 260.
Let’s say you have 40 characters for the directory path. If you can keep the cloning directory shorter than that it should work. However, this is only a temporary solution.
In links above, it is suggested so use msys library or install cygwin to overcome this limitation.
How much effort is required to implement a new resource (or to extend the capabilities of an already existing one)?
This question really depends on the components to develop.
A resource from scratch:
As explained in “Create a new resource section”, the required components to add support for a new resource type are:
- Model: Fabric independent representation of the status of a resource.
The model is the piece that varies the most between resources, and the on that takes more effort. Once the model is in place, the rest may be developed in a day or two.
With these components in place, a new resource type is supported. However, there is no way a user can interact with it unless capabilities are present.
A new capability:
To create a new capability, following components are required:
- Capability API: one must come an API expressing the functionality in a fabric independent fashion.
- Capability implementation using actions
- Driver: Capabilities require a fabric aware implementation for the actions it defines. A driver for desired fabric must be present for the capability to be functional.
Capability API and its implementation using actions may be implemented in a day or two. However, having a useful API is what really provides value, and to come up with the desired one is a design task that is to be done before implementing.
A new driver:
The most complex component is the driver. In order to use an existing capability in a particular device, a driver providing a specific implementation for that device of required actions must be present. A driver consists of actions implementations that make use of protocol session(s) to communicate with the device. Most of driver complexity is in having a client to manages the device remotely. This step may take weeks or even months. However, once that is accomplished, developing desired actions uses to be quite straightforward if the client has similar features, although it may be tiring depending on the number of actions to implement. Just to put some edge samples, it is not the same developing a driver calling a defined REST API, than another connecting to the device CLI over SSH and trying to parse from it. But, once you have a client that does what you want to do in the device, one should be able to integrate in into a driver in a week or two.
So the golden rule for creating a capability with its driver would be something like:
- Select the device you want to support.
- Tell the community what you want to do and if someone else is interested.
- Define what is the API you want to work with in OpenNaaS. The community is a very good place to gather ideas and suggestions about that.
- Create a java client that remotely connects to the device and performs atomic actions that applied together cause all desired transformations.
- Save a month to integrate that into OpenNaaS.
- Announce your results and share them with us! 😉
We have successfully tested OpenNaaS in Windows 7, Ubuntu 12.04 and MAC OSX systems. The minimal system requirements are:
- Oracle’s Java Runtime Environment (JRE) 1.6.x (Java 6).
- About 100 MB of free disk space, needed for running full OpenNaaS assembly.
The netconf subsystem for ssh connections is not enabled in the router. Thus, OpenNaaS netconf client cannot connect to the router device.
Netconf should be enabled in the router before trying to start the resource in OpenNaaS. You can find the problem description and its solution at http://jira.i2cat.net:8080/browse/OPENNAAS-238
Can OpenNaaS be integrated with other Management Solutions (Cloud Managmenet solutions, Network Management solutions)?
Today, OpenNaaS only supports partly OpenStack Neutron API. But, as far as the other Management Solution exposes an API, OpenNaaS can be used as a network manager of that solution. It should be considered that some implementation is needed to satisfy the specific requirements of the API.