ONAP adaptor demo: Packaging shortcuts and hacks

[mpeuster]

We (Kevin, GerogeA, Manuel) just had a call how to quickly build a working ONAP demo in the last two weeks of August, to be shown at the ONS.

@luishens01 correctly noticed that there might be problems with unpackager/catalogue which would require some implementation work that is not achievable in the available time. So, I (Manuel) propose the following shortcuts:

Problem

The unpackager and the package format are ready for putting ONAP artefacts into a 5GTANGO package. However, the catalogue can only distinguish between 5GTANGO and OSM artefacts right now. To extend this, we would need someone who could spend some weeks on catalogue developments, which does not seem to be possible right now.

Proposed Solution

We can create a normal 5GTANGO package (with a small fake 5GTANGO NSD inside) and put an unchanged ONAP package as an additional file into this package. Using this, the unpackager will store the package contents as a normal "5GTANGO" artefacts inside the catalogue and upload the "wrapped" ONAP package as an "arbitrary file" (like, e.g. a logo or script) to the catalogue from where it could be downloaded by the VnV.

This "fake" 5GTANGO package would contain a special tag, say ONAP-wrapped-by-5GTANGO, which would allow the VnV to still identify that this is a special package and to download the original ONAP package from the catalouge.

(yes, the package will be shown as 5GTANGO in the portal etc. but IMO that is not a big thing)

With this, no changes in the catalogue are needed.

Requirements

1. We need to create this "fake" package (@mpeuster will support here and create an example)
   1. We need the actual ONAP package to be wrapped (@allemaos @kweveen )
2. We need to make the VnV able to notice (based on tag) that the package in the catalogue is a "fake" 5GTANGO package containing a ONAP package and let it treat it correctly (@luishens01 ?)

Anything I forgot?

[mpeuster]

Can someone with the correct rights assign the mentioned people to this issue? I don't have any rights in this repo ;-)

[kweveen]

I think you covered everything @mpeuster. A general point worth mentioning is that our catalogue design should favour a more permissive approach for different package types. In addition, the "type" of package should be metadata from the tango package rather some strict enum that the catalogue maintains. These changes would allow greater flexibility for end-users and also better increase catalogue adoption.