Adaptation of Catalogues to OSM/ONAP descriptors

[panstav1]

@mpeuster Potential solution: An a-priori check in the schema. OSM descriptors have a characteristic schema of a field with only an object inside.

[mpeuster]

Would this mean I (the packager) have to push OSM descriptors to another REST endpoint?

[jbonnet]

@mpeuster @panstav1 How would the un-packager know about these multiple endpoints?

[panstav1]

@mpeuster @jbonnet No, nothing about packager or gatekeeper will change. The descriptors will be uploaded in one endpoint, as it is already now. The Catalogues will make an assessment of the schema and put the according to the type of descriptors into a field in the metadata (root level of descriptor) like "platform"={5gtango, osm,...}. Thus, nothing is changed from the designs, except for the tng-cat. I wanted your view on this, not changes in packager :) @mpeuster @jbonnet

[jbonnet]

Ah, @panstav1, ok, great! :-) Now, I'm OSM... how to I fetch descriptors from our Catalogue?

[panstav1]

@jbonnet This is possible with querying the catalogues with the ...vnfs?platform=osm&. Somehow needs to be clarified on the grounds that we will have this unified

[mpeuster]

@panstav1 Ah got it. I think it makes sense to just detect the type based on the descriptor structure as you propose +1.

@jbonnet Does OSM itself need to query out catalogues? I don't think so. But the VnV need to fetch the OSM descriptors and upload them to OSM if it wants to deploy a service on OSM ;-)

[panstav1]

Implemented in the current issue #66 . Now targeting to onap adaptation

[mpeuster]

Which changes will be needed from the packager side to support this? Do I have to include the "platform" during upload?

[panstav1]

@mpeuster In general, a field is added in the metadata. This satisfies two terms 1) The retrieval of descriptors in unified API, i.e. vnfs?platform=osm, 2) to define and reuse the same services in the Catalogues. Thus, the same old APIs are used and, by default, add the plaform field equal to 5gtango. To change this default operation, in the curl POST, you should use the argument "platform={5gtango,osm,onap}, .i.e. curl curl -H "Content-type : application/json" -X POST http://../vnfs?platform=osm (in case of osm). For tango descriptors, you can use either ../vnfs?platform=5gtango or the existing ones (if none parameter is given, then 5gtango is placed)

[jbonnet]

@panstav1 Better use the body of the POST, instead of http://../vnfs?platform=osm...

My 2 cents

[mpeuster]

@panstav1 fine for me. I'll create an issue for the packager.

@jbonnet Or an header? Not sure. For me all options are fine here.

[jbonnet]

@mpeuster right now it's implemented as an optional parameter in the body of the POST

[mpeuster]

mhm in the body of the POST? Do we have a curl example? Is the body a JSON dict?

[jbonnet]

Sorry, my bad, as one of the form parameters of the POST (but called format -- is it the same?), together with the package file, the callback_url, the layer and the skip_store flag set to false by default.

[panstav1]

After @jbonnet's request, i'll change this to add "platform" in the body of the POST:

curl -H "Content-type:application/json" -X POST http:<url>/vnfs --data-binary @file -d platform=osm

[mpeuster]

Ok, I will follow this. Just need to see when I can implement it.

[panstav1]

Finally, platform will be passed as optional parameter in POST request. An example:

curl -H "Content-type:application/json" -X POST http:/vnfs?platform={osm,onap,5gtango} --data-binary @file

If platform is absent, 5gtango is the default field, in order to be consistent with the previous development of the 5GTANGO Infrastructure. Changes are in #67 (onap) and #66 (osm)