sonata-nfv/tng-sdk-descriptorgen

5GTANGO descriptor generator

tng-sdk-descriptorgen's Issues

Documentation

Write documentation: Inline comments, Readme, (Wiki)

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

OSM descriptors: memory-gb doesn't exist

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

Generation using meta-description and command line for advanced users

To avoid using web interface

Integration with validation

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

Tests

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

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)

Deployment

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

/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.

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.

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?

Support for OSM descriptors

Support generating OSM descriptors

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.

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.

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 packaging & uploading

Allow reusing existing VNFs inside network services

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

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

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

Different kinds of VNFs

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

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