NBI IA Integration about tng-sp-ia-k8s

[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