From 2cd229ac8a60ec9e40962e782f7a580070043d0e Mon Sep 17 00:00:00 2001 From: garciadeblas Date: Thu, 5 Sep 2019 16:36:06 +0200 Subject: [PATCH] Support of multiple VCA instances and a platform-independent API in N2VC Change-Id: I1c3fb64abd2eb22946fc903e674915fdfe30e11b Signed-off-by: garciadeblas --- ..._and_a_platform-independent_API_in_N2VC.md | 66 +++++++++++++++++++ 1 file changed, 66 insertions(+) create mode 100644 Support_of_multiple_VCA_instances_and_a_platform-independent_API_in_N2VC.md diff --git a/Support_of_multiple_VCA_instances_and_a_platform-independent_API_in_N2VC.md b/Support_of_multiple_VCA_instances_and_a_platform-independent_API_in_N2VC.md new file mode 100644 index 0000000..0f83787 --- /dev/null +++ b/Support_of_multiple_VCA_instances_and_a_platform-independent_API_in_N2VC.md @@ -0,0 +1,66 @@ +# Support of multiple VCA instances and a platform-independent API in N2VC + +## Proposers + +- Gerardo Garcia (Telefonica) +- Alfonso Tierno (Telefonica) +- Francisco Javier Ramon (Telefonica) +- Adam Israel (Canonical) +- José Antonio Quiles (Indra) + +## Type + +Feature + +## Target MDG/TF + +N2VC, LCM + +## Description + +Currently, OSM assumes that management networks of all the VNF instances are remotely accessible +by OSM from outside the datacenter, either directly or via floating IPs, so that VCA can drive +successfully its operations with the VNFs. While this way of work has many advantages in telco +clouds it might be somewhat rigid in hybrid deployments where e.g. public clouds are involved. In +fact, this imposes some networking conditions to OSM so that VCA can access to all the +management networks of each target VIM. + +In addition, the current N2VC library is platform-dependent. Most of the API calls are juju-specific +instead of providing a higher level interface. + +While this shouldn't be an issue from the point of view of the actual behaviour of the OSM platform +as a whole, it has three main drawbacks: + +- Architecturally speaking, it breaks the general principles of abstraction and layering, percolating + terminology and way of thinking northbound. +- It complicates the implementation of features in LCM, since LCM needs to understand all the internals + of each call and figure out the actual state of N2VC and VCA internals. +- It locks the workflow in LCM, which cannot be modified without changing N2VC. As a result, almost + every new feature impacting N2VC (support of native charms, secure key management, support of + relations, NS primitives) forces to change in the workflow in LCM, as current workflows are entirely + VCA-oriented (rather than LCM-oriented) due to the aforementioned problem in layering. + +This feature is intended to re-define the N2VC API to restore the layering, make it truly +platform-independent (agnostic of the VCA terminology), and able to support multiple VCA instances. +It will require the implementation of a generic class in N2VC, defining those API calls and the +expected behaviour. + +The main premises of the new N2VC API would be the following: + +- **High-level abstraction API.** The current platform-dependent objects managed by N2VC (machines, + charms, models, applications) will be replaced by a new set of generic platform-independent objects + (execution environment, configuration SW, namespaces). +- Keep a decoupling among the elements to be configured, the configuration SW and the execution + environment, so that the workflows in current VCA can be reproduced. +- **API calls should be defined in such a way that allows to do things in parallel.** For instance, it + is not necessary to wait for the RO to finish the instantiation to before makeing VCA to create the + execution environments, or vice-versa. +- **Layering and isolation.** LCM workflow (sequence of N2VC calls) could change in the future and it + should not impact N2VC or vice-versa. +- **Transparency in progress of operation and states.** N2VC should be able to update directly the Mongo + records associated to the operation in progress. + +## Demo or definition of done + +All DEVOPS tests using VNF/NS packages with charms should work in the same way as they are working today. + -- 2.25.1