Service Platform-specific Gatekeeper component

This is the 5GTANGO Gatekeeper Service Platform specific components repository, which implements the Gatekeeper features that are specific to the 5GTANGO Service Platform.

For details on the overall 5GTANGO architecture please check here. The Gatekeeper is the component highlighted in the following picture.

You might also be interested in the following related repositories:

• V&V and Service Platforms common component;
• V&V Platform specific component.

Supported endpoints

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
/policies	Manages placement and run-time policies
/records/functions	Lists function records available in the Repository
/records/services	Lists service records available in the Repository
/requests	Manages services' and slices' lifecycle events (creation, scaling, deletion, etc.)
/slices	Manages slice templates

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-sp.git # Clone this repository
$ cd tng-gtk-sp # Go to the newly created folder
$ bundle install # Install dependencies
$ PORT=5000 bundle exec rackup # dev server at http://localhost:5000

Note: See the Configuration section below for other environment variables that can be used.

Everything being fine, you'll have a server running on that session, on port 5000. You can aesscc 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 (bash shell):

$ docker network create tango
$ docker run -d -p 27017:27017 --net=tango --name mongo mongo
$ docker run -d -p 5432:5432 --net=tango --name postgres postgres
$ docker run -d -p 5672:5672 --net=tango --name rabbitmq rabbitmq
$ 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-sp \
  -e CATALOGUE_URL=http://tng-cat:4011/catalogues/api/v2 \
  -e REPOSITORY_URL=http://tng-cat:4012 \
  -e MQSERVER_URL=amqp://guest:guest@rabbitmq:5672 \
  -e POSTGRES_PASSWORD=tango \
  -e POSTGRES_USER=tangodefault \
  -e DATABASE_HOST=postgres \
  -e DATABASE_PORT=5432 \
  sonatanfv/tng-gtk-sp:dev

Note: user and password are mere indicative, please choose the apropriate ones for your deployment.

With these commands, you:

1. Create a docker network named tango;
2. Run the MongoDB container within the tango network;
3. Run the PostgreSQL container within the tango network;
4. Run the RabbitMQ container within the tango network;
5. Run the Catalogue container within the tango network;
6. Run the Repository container within the tango network;
7. Run the SP-specific Gatekeeper container within the tango network, with the needed environment variables set to the previously created containers.

Developing

This section covers all the needs a developer has in order to be able to contribute to this project.

Dependencies

We are using the following libraries (also referenced in the Gemfile file) for development:

• activerecord (5.2), the Object-Relational Mapper (ORM);
• bunny (2.8.0), the adapter to the RabbitMQ message queue server;
• pg (0.21.0), the adapter to the PostgreSQL database;
• puma (3.11.0), an application server;
• rack (2.0.4), a web-server interfacing library, on top of which sinatra 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-activerecord (2.0.13),
• sinatra-contrib (2.0.2), several add-ons to sinatra;
• sinatra-cross_origin (0.4.0), a middleware to sinatra that helps in managing the Cross Origin Resource Sharing (CORS) problem;
• sinatra-logger (0.3.2), a logger middleware;

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 for rack-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 for rubocop;
• 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

Prerequisites

We usually use rbenv as the ruby version manager, but others like rvm may work as well.

Setting up Dev

Developing this micro-service is straightforward 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, while services 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.

Submiting changes

Changes to the repository can be requested using this repository's issues and pull requests mechanisms.

Versioning

The most up-to-date version is v4. For the versions available, see the link to tags on this repository.

Configuration

The configuration of the micro-service is done through the following environment variables, defined in the Dockerfile:

• CATALOGUE_URL, which defines the Catalogue's URL, where test descriptors are fetched from;
• REPOSITORY_URL, which defines the Repository's URL, where test plans and test results are fetched from;
• DATABASE_URL, which defines the database's URL, in the following format: postgresql://user:password@host:port/database_name (Note: this is an alternative format to the one described in the Installing from the Docker container section);
• MQSERVER_URL, which defines the message queue server's URL, in the following format: amqp://user:password@host:port

Tests

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.

These tests are executed by running the following command:

$ bundle exec rspec spec

Wider scope (integration and functional) tests involving this micro-service are defined in tng-tests.

Style guide

Our style guide is really simple:

1. 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.;
2. we use two spaces for identation.

API Reference

We have specified this micro-service's API in a swagger-formated file. Please check it there.

Licensing

This 5GTANGO component is published under Apache 2.0 license. Please see the LICENSE file for more details.

Feedback-Channel

• Please use the GitHub issues to report bugs.
• You may use the mailing list sonata-dev@lists.atosresearch.eu