NBI IA Integration

[felipevicens]

We need to integrate the wrapper with the NBI to receive instantiation requests. To that end, the following steps have to be performed:

Topic: infrastructure.k8s.function.deploy:

• [x] Define the fields received by the k8s Wrapper
• [x] Define format of the VNFR created by k8s Wrapper
• [x] Integration tests between IA <-> k8s Wrapper

Topic: infrastructure.k8s.function.remove:

• [x] Define the fields received by the k8s Wrapper

• [x] Define the reply of the function remove request

• [ ] Integration tests between IA <-> k8s Wrapper

• [x] Documentation

[carlos-martins-marques]

In the moment this is implemented:

topic: infrastructure.function.deploy data: {vim_uuid: String, service_instance_id: String, vnfd: SonataVnfDescriptor} return: { instanceName: String, instanceVimUuid: String, vimUuid: String, request_status: String, ip_mapping: [{ SonataIpMapping }], vnfr: SonataVnfRecord, message: String }, when request_status is "COMPLETED", message field is empty, when request_status is "ERROR", message field carries a string with the error message and the other fields are empty.

topic: infrastructure.function.remove data: {service_instance_id: String, vim_uuid: String, vnf_uuid: String} return: {request_status: String, message: String}, when request_status is "COMPLETED" message field is empty, when request_status is "ERROR", message field carries a string with the error message.

I think the differences will be the "vnfd: SonataVnfDescriptor" and the "vnfr: SonataVnfRecord". The vnfd that IA-NBI received is that is onborded, plus two fields added by mano (uuid and instance_uuid). The vnfr needs to be complaint with mano expects. IA-NBI is agnostic to this.

An example for vndf and vnfr currently used in wrapper heat unit tests can be found in this links: https://github.com/sonata-nfv/tng-sp-ia/blob/master/ia-nbi/adaptor/YAML/1-vnf.vnfd https://github.com/sonata-nfv/tng-sp-ia/blob/master/ia-nbi/adaptor/YAML/1-vnf.vnfr

Note: SonataIpMapping is the mapping between private ip and public ip (floating ip), code implementation: https://github.com/sonata-nfv/tng-sp-ia/blob/dfd06fc909a1d51247aecc9c49abd5d5e1272e64/ia-nbi/adaptor/src/main/java/sonata/kernel/adaptor/commons/IpMapping.java

[felipevicens]

Thanks, @carlos-martins-marques I would like to check with you and with @tsoenen if we need to expand the message for kubernetes VIM. In case of the VNFR, we have a set of fields that we could include it not only the deployment part but also the service. Maybe we will need more interactions between MANO and IA in order to enable the configuration of the service deployed in kubernetes. The handle of environment variables, config files, secrets, storage resources, specific resources like GPU.

[carlos-f-parada]

@carlos-martins-marques @felipevicens Today, the messages body (e.g. deploy) is basically the relevant fields on the descriptor (virtual_deployment_unit) translated to json. In this sense, I assume it would be just a matter of using the relevant fields on the descriptor (cloudnative_deployment_unit) translated to json. Regarding the VNFR, we need to discuss what fieds are relevant, as as I understood from you there is a lot of useful information that you can out there.

would say that the messages should

[felipevicens]

For the topic infrastructure.k8s.management.compute.list we agreed on the following list:

Payload: 
resources:
- core_total: 16
  cpu_used: 363950476
  memory_allocatable: 48934544
  memory_total: 49139344
  memory_used: 4231684
  vim_city: Athens
  vim_domain: 'null'
  vim_endpoint: 'null'
  vim_name: k8s
  vim_uuid: 8888-22222222-33333333-8888 

[felipevicens]

This is a VNFR example to used as base to return container service information: https://gist.github.com/felipevicens/84e251d0972d8c3c723db2cc21deb9f6

[felipevicens]

This is the mapping vnfr -> cnfs https://gist.github.com/felipevicens/598c3a6f172ddcf5285a9247a04c74e2