Release2/access_to_vnf_console.md

   1 # Access to VNF console #
   2
   3 ## Proposer ##
   4 **EUAG**
   5
   6 ## Type ##
   7 **Feature**
   8
   9 ## Target MDG/TF ##
  10 UI, SO, RO
  11
  12 ## Description ##
  13 Current implementation for Release 0 does not allow remote access to the VNF console (actually, any
  14 of the consoles of the VMs integrating the VNF). This kind of access from the OSM GUI to the VNF
  15 console is desirable as a last resort.
  16
  17 With PNFs today, access is typically done through telnet or ssh to configure a PNF. Through that
  18 process, it is possible to get access to a specific console that is not the typical Linux root
  19 Shell, but a different one exposing only specific configuration parameters.
  20
  21 With VNFs, two different approaches have been found:
  22 - In some cases, the access to the UI is through telnet or ssh in a similar way to PNFs.
  23 - In other cases, as a last resort, the access could be through a terminal accesible via VNC or
  24 spice, in a similar way to any other guest VM in the cloud.
  25
  26 This feature request is about the second approach: access to terminal via VNC or spice.
  27
  28 Two different situations are foreseen depending on the kind of VNF:
  29
  30 - Single-VM VNFs. Access to the VNF console is equivalent to access to the VM console
  31 - Multi-VM VNFs:
  32     - There is usually a VM for management purposes (OAM VM). Access to the VNF console would be
  33     equivalent to access to the OAM VM.
  34     - The operator will typically want to access the OAM VM of that multi-VM VNF, because from that
  35     VM it is possible to configure the whole VNF. However, under some circunstances (e.g. tests
  36     with VNF provider), it might be helpful to have access to every VM of a multi-VM VNF. Although
  37     its use would be less frequent for the end user, this is still an interesting feature to have
  38     for troubleshooting purposes.
  39     - In order to distinguish the console of the OAM VM from the rest of consoles, it should be
  40     possible that the VNF descriptor allowed to identify the VM whose console will be used as VNF
  41     console.
  42
  43 It is clear that, this feature requires the VIMs to be capable of creating terminals based on VNC
  44 or Spice. The VIM must build a URL for accessing the terminal through the hypervisor and, moreover,
  45 this URL must be exposed to RO.
  46
  47 The RO should read the URL of the VM consoles from the VIM and expose it to SO. The SO should offer
  48 that URL to the UI. The UI should present that URL to the end user so that he/she can just click on
  49 it and launch the appropriate application to access the VNF console. Ideally, the application
  50 console could be integrated with the UI, so that all consoles are opened as tabs in the UI.
  51
  52 From the UI perspective, it is expected that:
  53
  54 - The end user can inspect the VNFs running in an NS and click on any of them to open the VNF
  55 console. A dedicated button is suggested to open that console.
  56 - In case of a multi-VM VNF, besides the possibility to open the VNF console (equivalent to the OAM
  57 VM), the end user could inspect the running VMs and click on any of them to open the console of the
  58 VM. A dedicated button is also suggested to open that console.
  59
  60 ## Demo or definition of done ##
  61 A test case consisting of the deployment of an NS instance with 2 interconnected VNFs (A and B) is
  62 suggested. Both VNFs can be deployed in the same datacenter. VNF A might be a single-VM VNF, while
  63 VNF B might be a multi-VM VNF.
  64
  65 From the UI, it should be possible to access to the following consoles:
  66
  67 - Console of VNF A
  68 - Console of VNF B
  69 - Console of all VMs integrating VNF B
  70