sonata-nfv/tng-sdk-descriptorgen

5GTANGO descriptor generator

Note: The 5GTANGO descriptor generator is now integrated in the tng-sdk-project tool that provides the same functionality but also offers usage via a CLI and as a micro service with a REST API. Thus, the development in this repository is discontinued.

5GTANGO Descriptor Generator

The descriptor generator provides a simple web-based GUI that allows to setup and generate correct descriptors (VNFDs and NSDs). The generator uses provided high-level information and combines it with sensible default values to generate descriptors with a single click.

It generates descriptors both for 5GTANGO and for OSM. The resulting VNFDs and NSDs are displayed in the GUI and can still be adjusted as needed - directly in the GUI. The final descriptors can then be downloaded as complete 5GTANGO project (incl. a project manifest), which is ready for packaging and further use.

Installation and usage

Options:

• Directly access the descriptor generator without download or installation on https://sonata-nfv.github.io/tng-sdk-descriptorgen/ (auto. updated) or http://sdk.5gtango.eu/ (may be outdated)

• Download the repository and open index.html in a web browser to use it locally

• Download the repository and deploy the Descriptor Generator as a Docker container (see below). This allows offline use as the default descriptors are served and loaded locally rather than from GitHub.

Docker deployment

If you want to deploy the descriptor generator as a docker container, you can do so using the Dockerfile. The container will run a nginx webserver serving the descriptor generator. Simply download the repository and run from within:

• sudo docker build -f Dockerfile -t tng-sdk-descriptorgen:latest . to create the docker image
• sudo docker images to check that the image is there
• sudo docker run -d -p 80:80 --name descriptorgen --rm tng-sdk-descriptorgen:latest to start the docker container
• sudo docker container ls to check that the container is running
• Open localhost in your web browser to access the descriptor generation web interface
• sudo docker stop descriptorgen to stop the container

DockerfilePipeline is just used for the Jenkins pipeline.

Tests

To test that everything is working correctly, you can use the provided unit tests in the pipeline/unittest directory. The tests use the Protractor testing framework, which can be installed using

• npm install -g protractor
• sudo webdriver-manager update

Protractor needs Java, which can be installed using sudo apt-get install default-jdk on Ubuntu. Once installed, the unit tests can be executed with (inside the pipeline/unittest directory):

protractor conf.js

This triggers the tests using Chrome in headless mode. If and only if all tests finish successfully, protractor exits with code 0.

Documentation

See the general workflow below. For further information refer to the wiki.

Input

The web interface asks for high-level information about the network service such as author and service name. For all fields, default values are provided to support the easy and fast generation of new descriptors. Clicking the "Generate" button triggers the generation of the descriptors.

The GUI also allows to upload already existing VNFDs that should be included in a network service. The descriptorgen then automatically generates the other VNFDs and integrates the existing VNFD in the NSD. As a requirement, the uploaded VNFDs need the connection points input, output, and mgmt. To integrate an uploaded VNFD in a network service, simply select it in the left drop-down menu. For such uploaded VNFDs, the image is already defined such that the specified image name and type in the GUI is ignored.

Output

The generated descriptors are directly shown in code boxes that allow further manual adjustments and that provide yaml code highlighting. Once satisfied with the result, the descriptors can be downloaded individually or bundled together in a zip file.

Dependencies

The descriptor generator needs an active internet connection to fetch the current default descriptors from GitHub repositories (typically from tng-schema). All dependencies are included directly in the repository or are loaded in index.html - no installation required.

Development and contribution

Please check or create issues matching the current and future development steps.

Contribution is very welcome! Please, fork the repository and create pull requests to submit implemented features. Make sure all unit tests pass before creating a pull request.

Lead developers:

• Stefan Schneider (@stefanbschneider)
• Manuel Peuster (@mpeuster)

License

The descriptor generator is published under Apache 2.0 license. Please see the LICENSE file for more details.

tng-sdk-descriptorgen's Issues

Tests

Write tests that can be executed automatically to ensure correctness (also integration tests)

Documentation

Write documentation: Inline comments, Readme, (Wiki)

Generation of CNFs

• Update VNFD schema to include CNFs
• Create sample descriptor using a CNF
• Allow selecting VNFs with either regular VDU or CNF (or PNF)
• Use different base sample descriptors for generating the corresponding VNFDs
• Do the same for the CLI/REST tool in tng-sdk-project

Integration with tng-sdk-project

Overall goal: Online SDK editor running the different SDK tools, integrated via one web interface.

First step: Auto. create a folder structure and project.yml, when generating descriptors. Put the generated descriptors in there and download the whole folder, which is then ready for validation/packaging.

Test download of generated descriptors

Both in unit tests and for use in integration test with other SDK tools (eg, tng-sdk-project and package).

https://stackoverflow.com/a/27193881/2745116

Generation using meta-description and command line for advanced users

To avoid using web interface

Deployment

Ensure the generator is ready for deployment. Eg. inside a docker?

Better GUI

Nicer visuals. More responsive design.

• Submission via "Enter"
• YAML syntax highlighting in generated descriptors, eg, with Google's prettify
• Buttons for downloading/copying generated descriptors
• Allow adjusting high-level info and re-running generation

Publish on Dockerhub

For easier deployment.
Should happen automatically during the publication phase in Jenkins

Generation of Y1 review descriptors

What's the delta between normal, default descriptors generated by the descriptorgen now and the required descriptors for the Y1 review: https://github.com/sonata-nfv/tng-y1-demo

If its small, can the descriptorgen be (adjusted &) used in the review to generate the Y1 review descriptors?

Offline generation

Currently the default descriptors are fetched from GitHub (either tng-schema or this repository). Hence, the current descriptorgen doesn't work without internet.

For the demo, we should be able to generate offline - to be safe. Approach: Run web server locally that serves the default descriptors and fetch them from there.

Support for OSM descriptors

Support generating OSM descriptors

Integration with validation

For auto. validating generated descriptors
Ideally already mark input fields green or red depending on validity of input (compared to schemas)

Update generated OSM descriptors

Adjust/update generated OSM descriptors

Comparing newly created, compatible descriptors with previously generated descriptors:

NSD:

• Add vim-network-name: default and type: ELAN for all vlds
• Change default-vnf to vnf

VNFD:

• No input interface and connection point for first VNF
• No output interface and connection point for last VNF
• Change default-vnf to vnf

Refactor GUI

Either refactor the GUI (eg, using Angular) so other tools can be integrated like validation and packaging.

Or integrate all tools, including the descriptor generator, into the new portal GUI. This is probably the better option.
For this, I need to

• check the implementation of the portal
• implement the descriptor generation as backend with REST interface (currently under development in tng-sdk-project)

We should not use the exact same portal as for the VnV and the SP but a copy of it, showing some kind of "developer view/mode", which only shows the SDK tools, not the VnV and SP. This way we could still reuse and adjust the portal implementation, have a consistent look and feel, but have separate GUIs for developer and operator.

/ping endpoint

As proposed by José, every component should have a /ping endpoint that simply responds with a status 200, signaling it's still alive.

The descriptorgen doesn't really implement a Rest API (e.g., with Python) but only runs a web server inside a container that serves index.html. Going to the container's IP should show the descriptorgen GUI.

I just need a way that going to the container's IP/ping returns the status 200 message. Probably depends on nginx or Apache.

Allow reusing existing VNFs inside network services

Allow to upload the descriptor of an existing VNF to include in a network service.

Integration with packaging & uploading

Different kinds of VNFs

eg CPU-bound vs memory-bound => different default values

OSM descriptors: memory-gb doesn't exist

Apparently only memory-mb --> update default descriptors. Also check for project

Easy generation of demo NSD & VNFDs

For demos (e.g., at the Y1 review), we'll use services like the ones from upb-emulator-mano-integration-demo or upb-containernet-emulator-summerschool-demo:

User --> Squid proxy --> Socat L4FW --> Apache webserver

For a demo, the descriptorgen should be able to generate descriptors for all VNFs and the complete NS place them in a project folder together with project.yaml. The following steps are still needed:

• Probably don't need monitoring parameters
• Allow referencing VM image (string) and format (drop-down) for each VNF
• Optionally use locally stored default NSD and VNFD rather than fetching them from the tng-schema repository. This is useful to quickly adjust these default NSDs during a demo.
• Generate project structure
• Test the generated descriptors with the service platform to check if they really work (integration env)

Different ordering of VNFs

Support different kinds of VNFs (see reuse of own VNFs) and let the user decide in which order they are chained. Ideally, represent the order visually