sonata-nfv / tng-sp-ia-k8s

5GTANGO repository for the Service Platform Kubernetes Infrastructure Abstraction Wrapper
Apache License 2.0
0 stars 4 forks source link

Extentions to support scaling #38

Closed tsoenen closed 5 years ago

tsoenen commented 5 years ago

To scale, the MANO will be sending on the topic for cnf deployment and cnf removal. The k8s wrapper needs to be smart with these messages to see when it is a scale event.

adding CNF

topic: infrastucture.k8s.function.deploy

payload example:

service_instance_id: ff0757e7-0d29-417d-8b63-cba80b6ffd9d
vim_uuid: 88888888-2222-3333-4444-888888888888
vnfd:
  author: 5GTANGO Test Team
  cloudnative_deployment_units:
  - connection_points:
    - fip: true
      id: data
      network_id: ff0757e7-0d29-417d-8b63-cba80b6ffd9d_ns_data-2-cnfs
      port: 1883
    id: cdu01-dfe39daa-0538-4133-8de1-d3cf6b43d14a
    image: ubuntu:trusty
  connection_points:
  - id: data
    interface: ipv4
    port: 1883
    type: serviceendpoint
  description: This is a integration test artifact
  descriptor_schema: https://raw.githubusercontent.com/sonata-nfv/tng-schema/master/function-descriptor/vnfd-schema.yml
  function_specific_managers:
  - description: FSM to do some dummy config on the ubuntu image for testing purposes
    id: ubuntuk8s
    image: tsoenen/ubuntuk8s-fsm
    options:
    - key: type
      value: start
    - key: type
      value: configure
  instance_uuid: dfe39daa-0538-4133-8de1-d3cf6b43d14a
  name: cnf1
  uuid: 2dcbf6f1-8019-404e-af24-d59b77fb9f97
  vendor: eu.5gtango
  version: '0.1'
  virtual_links:
  - connection_points_reference:
    - data
    - cdu01:data
    connectivity_type: E-Tree
    id: data-link

When the k8s wrapper receives a message on the .deploy topic, it needs to use the service_instance_id, the vnfd (e.g. image urls) and vim_uuid to check if there is already a pod for this vnfd part of the service instance. If it is, we just need another replica for this pod. If it is not, regular deployment needs to be followed. The response from the wrapper on this message should be the same for both cases.

Removing CNF

topic: infrastructure.k8s.function.remove

example payload:

service_instance_id:
vim_uuid:
vnf_uuid:

When reciving requests to remove a cnf, the K8s wrapper should check which pod is linked to this CNF (based on vim, vnf and service instance id) and check the amount of replicas. If higher than 1, reduce the number by 1. If 1, remove the pod. Responses to the MANO should be similar for both cases. Currently, the functionality for both cases is missing, for now this topic is not correctly handled. A response to a request on this topic looks like this

request_status: "COMPLETED" | "ERROR"
message: None | "possible error message"
felipevicens commented 5 years ago

Implemented!