1 # Support of multiple VCA instances and a platform-independent API in N2VC
5 - Gerardo Garcia (Telefonica)
6 - Alfonso Tierno (Telefonica)
7 - Francisco Javier Ramon (Telefonica)
8 - Adam Israel (Canonical)
9 - José Antonio Quiles (Indra)
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.
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.
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:
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.
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
48 The main premises of the new N2VC API would be the following:
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.
63 ## Demo or definition of done
65 All DEVOPS tests using VNF/NS packages with charms should work in the same way as they are working today.