Enable CNF list inside NS instances

[felipevicens]

There is a new fiel "cloudnative_deployment_unit" that contains the information about the CNF inside the NS, As example of vnfr reply:

{
  "cloudnative_deployment_units": [
    {
      "connection_points": [
        {
          "type": "serviceendpoint",
          "id": "rtmp",
          "port": 1935
        },
        {
          "type": "serviceendpoint",
          "id": "api",
          "port": 5000
        },
        {
          "type": "serviceendpoint",
          "id": "stats",
          "port": 80
        }
      ],
      "id": "cdu01",
      "image": "ignaciodomin/media-aggregator:dev",
      "vim_id": "8888-22222222-33333333-8888",
      "cdu_reference": "ma-vnfdcdu01-4ef2f66d-3263-43b9-a916-b6682f898b62",
      "load_balancer_ip": {
        "floating_ip": "172.31.13.44",
        "internal_ip": "10.106.128.182"
      },
      "number_of_instances": 1
    }
  ],
  "created_at": "2019-01-21T09:12:08.796+00:00",
  "descriptor_reference": "a35fbf4b-d1fa-4693-aab4-a9647338f413",
  "descriptor_version": "vnfr-schema-01",
  "status": "normal operation",
  "updated_at": "2019-01-21T09:12:08.796+00:00",
  "version": "2",
  "virtual_links": [
    {
      "id": "rtmp-link",
      "connectivity_type": "E-Tree",
      "connection_points_reference": [
        "rtmp",
        "cdu01:int-rtmp"
      ]
    },
    {
      "id": "api-link",
      "connectivity_type": "E-Tree",
      "connection_points_reference": [
        "api",
        "cdu01:int-api"
      ]
    },
    {
      "id": "stats-link",
      "connectivity_type": "E-Tree",
      "connection_points_reference": [
        "stats",
        "cdu01:int-stats"
      ]
    }
  ],
  "uuid": "4ef2f66d-3263-43b9-a916-b6682f898b62"
}

[anapolg]

@felipevicens CDUs have a different schema from VDUs. It is not only a matter of allowing the parameter "cloudnative_deployment_units", I need to know what parameters you want to display in here cause they are not the same as in the case of VDUs.

In VNF I am displaying:

• ID of the VDU
• ID, type, IP and MAC of the connetion point
• vc_id of the vnfc_instance

Also, I would strongly recommend to follow a similar schema for both VNF and CNF. In the case of VNF we have an object including the property vnfc_instance (array) whose elements include the property connection_points among others. Why the CDU doesn't have a property "cnfc_instances" (as an array) and under that "connection points"? Or the opposite, is it necessary to have a property "vnfc_instance" in the VDUs? Why not directly the "connection_points"?

Here you have two complete examples of function records in the case of VNF and CNF.

VNF

{  
   "created_at":"2019-01-11T15:04:22.479+00:00",
   "descriptor_reference":"1bdf5608-3a95-49b0-8a89-c4b2d39ee2a1",
   "descriptor_version":"vnfr-schema-01",
   "status":"normal operation",
   "updated_at":"2019-01-11T15:04:22.479+00:00",
   "version":"2",
   "virtual_deployment_units":[  
      {  
         "vdu_reference":"rp-vnf:vdu01-02ef1d9b-77a3-4234-8ed1-698e5ea10952",
         "vm_image":"http://www.google.es",
         "id":"vdu01",
         "resource_requirements":{  
            "memory":{  
               "size_unit":"GB",
               "size":2
            },
            "storage":{  
               "size_unit":"GB",
               "size":30
            },
            "cpu":{  
               "vcpus":1
            }
         },
         "vnfc_instance":[  
            {  
               "connection_points":[  
                  {  
                     "id":"mgmt",
                     "interface":{  
                        "address":"10.120.0.207",
                        "hardware_address":"fa:16:3e:7d:62:a6"
                     },
                     "type":"management"
                  },
                  {  
                     "id":"external",
                     "interface":{  
                        "address":"10.120.0.195",
                        "hardware_address":"fa:16:3e:78:83:0c"
                     },
                     "type":"external"
                  },
                  {  
                     "id":"internal",
                     "interface":{  
                        "address":"172.20.0.236",
                        "netmask":"255.255.255.248",
                        "hardware_address":"fa:16:3e:01:c5:69"
                     },
                     "type":"internal"
                  }
               ],
               "id":"0",
               "vim_id":"1111-22222222-33333333-4444",
               "vc_id":"0b07743f-33bf-49b2-8e99-62bf4983d7b3"
            }
         ],
         "number_of_instances":1
      }
   ],
   "virtual_links":[  
      {  
         "id":"vlmgmt",
         "connectivity_type":"E-Line",
         "connection_points_reference":[  
            "vdu01:mgmt",
            "cpmgmt"
         ]
      },
      {  
         "id":"vlexternal",
         "connectivity_type":"E-Line",
         "connection_points_reference":[  
            "vdu01:external",
            "cpexternal"
         ]
      },
      {  
         "id":"vlinternal",
         "connectivity_type":"E-Line",
         "connection_points_reference":[  
            "vdu01:internal",
            "cpinternal"
         ]
      }
   ],
   "uuid":"02ef1d9b-77a3-4234-8ed1-698e5ea10952"
}

CNF

{  
   "cloudnative_deployment_units":[  
      {  
         "vim_id":"8888-22222222-33333333-8888",
         "number_of_instances":1,
         "load_balancer_ip":{  
            "floating_ip":"10.200.16.16",
            "internal_ip":"10.97.154.229"
         },
         "connection_points":[  
            {  
               "type":"serviceendpoint",
               "port":1935,
               "id":"rtmp"
            },
            {  
               "type":"serviceendpoint",
               "port":80,
               "id":"hls"
            }
         ],
         "image":"ignaciodomin/media-streaming-engine:demo1",
         "id":"cdu01",
         "cdu_reference":"mse-vnfdcdu01-c16545c3-5d82-49ae-a8d4-71868e0c1d74"
      }
   ],
   "created_at":"2019-01-26T21:05:22.877+00:00",
   "descriptor_reference":"16aa0f2f-a358-4449-a101-70b44f45552a",
   "descriptor_version":"vnfr-schema-01",
   "status":"normal operation",
   "updated_at":"2019-01-26T21:05:22.877+00:00",
   "version":"2",
   "virtual_links":[  
      {  
         "connectivity_type":"E-Tree",
         "id":"rtmp-link",
         "connection_points_reference":[  
            "rtmp",
            "cdu01:int-rtmp"
         ]
      },
      {  
         "connectivity_type":"E-Tree",
         "id":"hls-link",
         "connection_points_reference":[  
            "hls",
            "cdu01:int-hls"
         ]
      }
   ],
   "uuid":"c16545c3-5d82-49ae-a8d4-71868e0c1d74"
}

[anapolg]

Change VNF ID in the table for VNF name ( cc @tsoenen @felipevicens )

Generate a CNF section as the VNF one. This will have a list with: -> ID (change ID per name cc @tsoenen ), status, Updated at

The detailed view will include: -> load_balancer_ip.floating_ip and load_balancer_ip.floating_ip

Meeting notes: https://git.cs.upb.de/5gtango/generalInfo/wikis/tango-wp5-2019-04-02

[tsoenen]

On the subject of having a + and - sign next to VNFs to scale out / in:

The - sign doesn't really make sense, as you have to specify which VNF you want to remove for the scale in. It could be better to use a x sign next to each VNF to indicate this. Clicking the + sign multiple times results in individual scale-out requests with one instance. With some sort of input textbox next to the VNF, you could indicate how many you want to scale out.