sonata-nfv / son-catalogue Goto Github PK

Basic syntactical validation

In the Service Platform (SP) catalogues the chosen data format is YAML at API level but catalogues work internally with JSON files. For the SDK, there is the option to accept both data format at API level:

Option A: Use YAML files with content type 'application/x-yaml'

Option B: Use both YAML files with content type 'application/x-yaml'
and JSON files with content type 'application/json' (allowing compatibility)

Part of user story sonata-nfv/son-cli/issues/60

Deploy this service as part of the int-sdk_integration jenkins job

Helper function to validate a descriptor syntax against a schema.

Due to validation against schema, next Catalogue fields must be removed from descriptors:
'created' field
'updated' field
'_id' field

Some GET method might return more than one entry (descriptor) from the catalogue. However, they just return one entry. Methods affected are:

GET name/last
GET name/version

This is due Group field, which adds the possibility to have the next situation:
NSD:
'ns_group': 'sonata1'
'ns_name': 'firewall'
'ns_version': '0.1'

NSD:
'ns_group': 'sonata2'
'ns_name': 'firewall'
'ns_version': '0.1'

The result for these methods must be a list containing both NSDs.

Create the Dockerfile
Create the docker-compose file

required for user story sonata-nfv/son-cli/issues/60

https://www.digitalocean.com/community/tutorials/how-to-package-and-distribute-ruby-applications-as-a-gem-using-rubygems

docker.io/knickers/mongo-express is not available, don't know if temporarily or definitely. As a consequence, integration tests involving the SDK catalogue are failing to start.

The source files' headers of this repository are incomplete. In the 4th paragraph "Neither the name of the SONATA-NFV [, ANY ADDITIONAL AFFILIATION]", the additional affiliation is missing.

It was proposed to use a name convention to identify services inside catalogues by using "group.name.version". However, each NS/VNF Descriptor includes a field called "ns_name" (or "vnf_name") and might include a field called "_id" generated when a service is stored in the catalogue.
Which is the approach to follow?
Example A:
No '_id' field
'name': 'group.name.version'

Example B:
'_id': 'group.name.version'
'name': 'service_name'

Y2 feature possibility:
Should SDK Catalogue store SSM/FSM descriptors?

This issue is related with the identifier (ID) of the NS / VNF Descriptor for the son-catalogue component.

Q: ID Format: What is the specific ID format? int, uuid, string, ...
In the current implementation, the ID is considered an integer, however this can be adapted to the specified format.

Q: ID Uniqueness (versioning): Is the NS/VNF Descriptor ID unique in the SDK or SP environment?
This question is related with versioning in the son-catalogue component. In the current implementation, a Descriptor has a unique ID, so this means that no other Descriptor will have the same ID but they can have the same Name, different Version. To extend this, an example is:

NSD Example ->
"id": "001"
"name": "TEST"
"version": "1.0"

Then some developer updates this NSD and stores it in the son-catalog, where we will have:

NSD Example "updated" ->
"id": "002"
"name": "TEST"
"version": "1.1"

Due to a re-design for Y2 SONATA Catalogues, SDK Catalogue will be merged into son-catalogue-repos component from Service Platform and end support on October 31th, milestone Y2B.
Any SDK component using SDK Catalogue should use file system to keep local descriptors and packages.

Service Developer wants to access the SP catalogue to see what validated service descriptors are available under his/her subscription

SDK Catalogue is no longer supported and a component of the SONATA's SDK.
SDK Catalogue functionalities are merged into son-catalogue-repos component of SONATA's Service Platform.
This repository could be closed by this date.

GET methods must add :group attribute for NSD/VNFD.

We need to add checkstyling verification for code quality issues

In the case of ruby, we need to add this gems in the Gemfile:

 gem 'rubocop'
 gem 'rubocop-checkstyle_formatter', require: false

Next feature for Y1C - Y1D time slot would be the implementation of the Catalogue for meta-data (descriptors) for Package/Project on the SDK

Service Developer wants to delete/remove a particular service descriptor from the SDK catalogue

I noticed that making a request to obtain a list of all VNFs (GET /vnfs) only returns the first two VNFs of the catalogue database. Can you confirm this issue?

Will we use 'small integers' IDs, or should we go for a UUIDs?

A Service Developer wants to publish/update a version of his/her service descriptor in the SP Catalogue

A Service Developer wants to publish/update his/her service descriptor in its local SDK Catalogue -> Create a internal UUID for each descriptor.

Hello,
how are vnf images supposed to be uploaded to the catalogue? Right now it only seems to be possible to upload the yaml descriptors, but not the corresponding/referenced vm-images

Set version for each gem on Gemfile from current release v0.9

Feature for update services on Catalogues (NSD / VNFD) is implemented, but it currently allows to have multiple Descriptors objects with different ID but same Name, Group or Version.