sonata-nfv / son-gkeeper Goto Github PK

Forgot to remove the mock used in Unit Tests

Just a very simple one.

as initial step for year 1 demo we would like to implement a simple deploy service flow.
more details from the MANO framework side can be found here -
sonata-nfv/son-mano-framework#23.

we need to define the GK-MANO API as the GK will be invoking the process in the MANO framework.

Only from the Package Management module, for now.

We're using GitHub's Issues and Milestones. I need to summarize how it works. Possibly look also into Waffle.io.

Get an IP address with a web server where to deploy the Gatekeeper's API v1 definition in Swagger.

What should happen when a 'duplicated' (to be defined) package is submitted (POST) to the Gatekeeper? It should be rejected (HTTP error 405 Method Not Allowed), right?

In the Heidelberg meeting we've decided to reuse T-NOVA's Infrastructure Repository (see code here). We need to increase our knowledge about it.

See the user story here

Duplicate #137

How the validated Package (.zip) will be stored by the SP-Catalogue.
Initial Thoughts: Once the GK, after validation, sends the package descriptor, along with the extracted respective NSD and VNFDs, it will store it ... and similarly it will store the package (.zip) like it would do for an image for an VNF .. the mongoDB will have a URI pointing to the .zip file of a stored package descriptor ..

Let's open the discussion on this subject.

About the simple(r) tests: since tests are code, and we won't have tests to the test the testing code (!!), testing code must be really simple. Otherwise it's easier for bugs to sneak in testing code.

When the GK passes a PD, NSD and VNFD to the CTLS, points of failure are:

1. the request fails (with a timeout) 'cause there's a network problem;
2. the request fails (with a timeout) 'cause the CTLS service is not available;
3. the request succeeds, the xDs are stored (totally or partially) but the response never reach the GK (might be the same as 1.1 or 1.2 above);
4. the request succeeds, the response reaches the GK, but not all the xDs are successfully stored (some might be invalid, duplicated, etc.)
5. others?

Tests 1. and 2. might be seen as Unit Tests for the GK (not yet implemented, btw). So, suggested integration tests between the Gatekeeper (GK) and the Catalogues (CTLS) include (but are not restricted to) the following:

1. Inconsistencies when the GK doesn't receive the response, though the CTLS has sent it;
2. Inconsistencies when only some of the xDs are stored
3. others?

RIFT.io, an OpenSource orchestrator.

There's information on how to install the Infrastructure Repository (to be provided later), but we need to do it by using Ansible.

In the Heidelberg meeting we've decided to use Swagger as the API definition and documentation tool. We need to know (more) about it.