Verification & Validation platform-specific Gatekeeper component
Please see details on the overall 5GTANGO architecture here. The Gatekeeper is the component highlighted in the following picture.
Installing / Getting started
This component is implemented in ruby, version 2.4.3.
Installing from code
To have it up and running from code, please do the following:
$ git clone https://github.com/sonata-nfv/tng-gtk-vnv.git # Clone this repository $ cd tng-gtk-vnv # Go to the newly created folder $ bundle install # Install dependencies $ PORT=5000 bundle exec rackup # dev server at http://localhost:5000
Everything being fine, you'll have a server running on that session, on port
5000. You can use it by using
curl, like in:
$ curl <host name>:5000/
Installing from the Docker container
In case you prefer a
docker based development, you can run the following commands (
$ docker network create tango $ docker run -d -p 27017:27017 --net=tango --name mongo mongo $ docker run -d -p 4011:4011 --net=tango --name tng-cat sonatanfv/tng-cat:dev $ docker run -d -p 4012:4012 --net=tango --name tng-rep sonatanfv/tng-rep:dev $ docker run -d -p 5000:5000 --net=tango --name tng-gtk-vnv \ -e CATALOGUE_URL=http://tng-cat:4011/catalogues/api/v2 \ -e REPOSITORY_URL=http://tng-cat:4012 \ sonatanfv/tng-gtk-vnv:dev
With these commands, you:
- Create a
- Run the MongoDB container within the
- Run the Catalogue container within the
- Run the Repository container within the
- Run the V&V-specific Gatekeeper container within the
tangonetwork, with the
REPOSITORY_URLenvironment variables set to the previously created containers.
This section covers all the needs a developer has in order to be able to contribute to this project.
We are using the following libraries (also referenced in the
Gemfile file) for development:
3.11.0), an application server;
2.0.4), a web-server interfacing library, on top of which
sinatrahas been built;
12.3.0), a dependencies management tool for ruby, similar to make;
2.0.2), a web framework for implementing efficient ruby APIs;
2.0.2), several add-ons to
0.4.0), a middleware to
sinatrathat helps in managing the
Cross Origin Resource Sharing (CORS)problem;
The following gems (libraries) are used just for tests:
1.0.0), a library for helping in generating continuous integration (CI) test reports;
0.8.2), a helper testing framework for
3.7.0), a testing framework for ruby;
0.52.0), a library for white box tests;
0.4.0), a helper library for
3.1.1), which alows mocking (i.e., faking) HTTP calls;
These libraries are installed/updated in the developer's machine when running the command (see above):
$ bundle install
Setting up Dev
Developing this micro-service is straight-forward with a low amount of necessary steps.
Routes within the micro-service are defined in the
config.ru file, in the root directory. It has two sections:
requiresection, where all used libraries must be required (Note:
controllershad to be required explicitly, while
servicesdo not, due to a bug we have found to happened in some of the environments);
mapsection, where this micro-service's routes are mapped to the controller responsible for it.
This new or updated route can then be mapped either into an existing controller or imply writing a new controller. This new or updated controller can use either existing or newly written services to fullfil it's role.
For further details on the micro-service's architecture please check the documentation.
The most up-to-date version is v4. For the versions available, see the link to tags on this repository.
The configuration of the micro-service is done through just two environment variables, defined in the Dockerfile:
CATALOGUE_URL, which should define the Catalogue's URL, where test descriptors are fetched from;
REPOSITORY_URL, which should define the Repository's URL, where test plans and test results are fetched from;
Unit tests are defined for both
services, in the
/spec folder. Since we use
rspec as the test library, we configure tests in the
spec_helper.rb file, also in the
To run these tests you need to execute the follwoing command:
$ CATALOGUE_URL=... REPOSITORY_URL=... bundle exec rspec spec
Wider scope (integration and functional) tests involving this micro-service are defined in
Our style guide is really simple:
- We try to follow a Clean Code philosophy in as much as possible, i.e., classes and methods should do one thing only, have the least number of parameters possible, etc.;
- we use two spaces for identation.
We have specified this micro-service's API in a swagger-formated file. Please check it there.
This 5GTANGO component is published under Apache 2.0 license. Please see the LICENSE file for more details.