Support_of_multiple_VCA_instances_and_a_platform-independent_API_in_N2VC.md

   1 # Support of multiple VCA instances and a platform-independent API in N2VC
   2
   3 ## Proposers
   4
   5 - Gerardo Garcia (Telefonica)
   6 - Alfonso Tierno (Telefonica)
   7 - Francisco Javier Ramon (Telefonica)
   8 - Adam Israel (Canonical)
   9 - José Antonio Quiles (Indra)
  10
  11 ## Type
  12
  13 Feature
  14
  15 ## Target MDG/TF
  16
  17 N2VC, LCM
  18
  19 ## Description
  20
  21 Currently, OSM assumes that management networks of all the VNF instances are remotely accessible
  22 by OSM from outside the datacenter, either directly or via floating IPs, so that VCA can drive
  23 successfully its operations with the VNFs. While this way of work has many advantages in telco
  24 clouds it might be somewhat rigid in hybrid deployments where e.g. public clouds are involved. In
  25 fact, this imposes some networking conditions to OSM so that VCA can access to all the
  26 management networks of each target VIM.
  27
  28 In addition, the current N2VC library is platform-dependent. Most of the API calls are juju-specific
  29 instead of providing a higher level interface.
  30
  31 While this shouldn't be an issue from the point of view of the actual behaviour of the OSM platform
  32 as a whole, it has three main drawbacks:
  33
  34 - Architecturally speaking, it breaks the general principles of abstraction and layering, percolating
  35   terminology and way of thinking northbound.
  36 - It complicates the implementation of features in LCM, since LCM needs to understand all the internals
  37   of each call and figure out the actual state of N2VC and VCA internals.
  38 - It locks the workflow in LCM, which cannot be modified without changing N2VC. As a result, almost
  39   every new feature impacting N2VC (support of native charms, secure key management, support of
  40   relations, NS primitives) forces to change in the workflow in LCM, as current workflows are entirely
  41   VCA-oriented (rather than LCM-oriented) due to the aforementioned problem in layering.
  42
  43 This feature is intended to re-define the N2VC API to restore the layering, make it truly
  44 platform-independent (agnostic of the VCA terminology), and able to support multiple VCA instances.
  45 It will require the implementation of a generic class in N2VC, defining those API calls and the
  46 expected behaviour.
  47
  48 The main premises of the new N2VC API would be the following:
  49
  50 - **High-level abstraction API.** The current platform-dependent objects managed by N2VC (machines,
  51   charms, models, applications) will be replaced by a new set of generic platform-independent objects
  52   (execution environment, configuration SW, namespaces).
  53 - Keep a decoupling among the elements to be configured, the configuration SW and the execution
  54   environment, so that the workflows in current VCA can be reproduced.
  55 - **API calls should be defined in such a way that allows to do things in parallel.** For instance, it
  56   is not necessary to wait for the RO to finish the instantiation to before makeing VCA to create the
  57   execution environments, or vice-versa.
  58 - **Layering and isolation.** LCM workflow (sequence of N2VC calls) could change in the future and it
  59   should not impact N2VC or vice-versa.
  60 - **Transparency in progress of operation and states.** N2VC should be able to update directly the Mongo
  61   records associated to the operation in progress.
  62
  63 ## Demo or definition of done
  64
  65 All DEVOPS tests using VNF/NS packages with charms should work in the same way as they are working today.
  66