This is the 5GTANGO Gatekeeper Verification and Validation platform specific components repository, which closely follows its SP Platform counterpart, complementing the common component repository .
Please see details on the overall 5GTANGO architecture here. The Gatekeeper is the component highlighted in the following picture.
Supported endpoints, alphabetically sorted, are described next. These endpoints are internal, only the ones exposed by the router in the Service Platform's and V&V Platform's routing files are available from the outside.
Endpoints | Description |
---|---|
/ |
The root of the API |
/pings |
The module's readiness and liveness endpoint |
/descriptors |
Lists available test descriptors (TDs) in the Catalogue |
/plans |
Manages test plans |
/results |
Lists available test results (TRs) in the Repository |
This component is implemented in ruby, version 2.4.3.
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/
In case you prefer a docker
based development, you can run the following commands (bash
shell):
$ 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
docker
network namedtango
; - Run the MongoDB container within the
tango
network; - Run the Catalogue container within the
tango
network; - Run the Repository container within the
tango
network; - Run the V&V-specific Gatekeeper container within the
tango
network, with theCATALOGUE_URL
andREPOSITORY_URL
environment 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:
puma
(3.11.0
), an application server;rack
(2.0.4
), a web-server interfacing library, on top of whichsinatra
has been built;rake
(12.3.0
), a dependencies management tool for ruby, similar to make;sinatra
(2.0.2
), a web framework for implementing efficient ruby APIs;sinatra-contrib
(2.0.2
), several add-ons tosinatra
;sinatra-cross_origin
(0.4.0
), a middleware tosinatra
that helps in managing theCross Origin Resource Sharing (CORS)
problem;
The following gems (libraries) are used just for tests:
ci_reporter_rspec
(1.0.0
), a library for helping in generating continuous integration (CI) test reports;rack-test
(0.8.2
), a helper testing framework forrack
-based applications;rspec
(3.7.0
), a testing framework for ruby;rubocop
(0.52.0
), a library for white box tests;rubocop-checkstyle_formatter
(0.4.0
), a helper library forrubocop
;webmock
(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
We usually use rbenv
as the ruby version manager, but others like rvm
may work as well.
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:
- The
require
section, where all used libraries must be required (Note:controllers
had to be required explicitly, whileservices
do not, due to a bug we have found to happened in some of the environments); - The
map
section, 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.
Changes to the repository can be requested using this repository's issues and pull requests mechanisms.
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 controllers
and 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 /spec
folder.
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 tng-tests
.
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.
- Please use the GitHub issues to report bugs.
- You may use the mailing list sonata-dev@lists.atosresearch.eu