From 977ccd22e37b1015d42df68c3da9785757fa9002 Mon Sep 17 00:00:00 2001 From: =?utf8?q?Francisco-Javier=20Ram=C3=B3n=20Salguero?= Date: Mon, 4 Feb 2019 04:00:05 +0100 Subject: [PATCH] Allow instantiation parameters in cloud-init MIME-Version: 1.0 Content-Type: text/plain; charset=utf8 Content-Transfer-Encoding: 8bit Change-Id: Iff59e8d0aa02b9241e204e71790545343229b832 Signed-off-by: Francisco-Javier Ramón Salguero --- ... instantiation parameters in cloud-init.md | 57 +++++++++++++++++++ 1 file changed, 57 insertions(+) create mode 100644 Release6/Allow instantiation parameters in cloud-init.md diff --git a/Release6/Allow instantiation parameters in cloud-init.md b/Release6/Allow instantiation parameters in cloud-init.md new file mode 100644 index 0000000..9cd08f3 --- /dev/null +++ b/Release6/Allow instantiation parameters in cloud-init.md @@ -0,0 +1,57 @@ +# Allow instantiation parameters in cloud-init + +## Proposer + +- Gerardo Garcia (Telefonica) +- Alfonso Tierno (Telefonica) +- Francisco Javier Ramon (Telefonica) + +## Type + +**Feature** + +## Target MDG/TF + +NBI, LCM, RO + +## Description + +OSM currently provides a mechanism to pass parameters when an instantiation (of +NS or NSI) is triggered, so that different instances created out of the same +NS/Slice Package may run with slightly different initial conditions -such as +different IP addressing, different QoS definitions, more/less centralization, +etc.-, which would be modelled as variables/inputs in the Package definition. +Currently, two kinds of mechanisms (non-mutually exclusive) to consume those +instantiation parameters are available: + +1. Indications of VIM target for a given VNF. These are passed to RO to deploy +the VNFs accordingly. +2. Initial configuration parameters. These are passed to VCA so that initial +configuration can be influenced by these parameters. + +This feature specifies a third mechanism of consumption of instantiation +parameters, so that some parameters might be directly mapped to initial config +files/templates, passed via cloud-init. This would largely simplify the initial +parametrization of those VNFs where some parameters might be trivially mapped +to fields in initial config templates. This would bring two benefits: + +- It would make the onboarding and parametrization of some simple/static VNFs +much simpler. +- Much faster instantiation of VNFs which required complex parametrizable +configurations, avoiding the need of multiple/complex transactions. + +This mechanism should be able to coexist the other two other mechanisms, even +in the same VNFs, where different subsets of instantiation parameters at VNF +level might trigger different types of operations. + +## Demo or definition of done + +- Create a VNF Package that embeds a config template with placeholders where +some instantiation parameters might be directly mapped. +- Instantiate a NS that uses such a VNF, passing the appropriate instantiation +parameters to be mapped to the template. +- Check that the applied configuration corresponds to the parameters that were +passed via this mechanism. +- Check whether parameters marked as mandatory are not provided. If so, an +error message should be issued, indicating clearly what parameter is needed in +which VNF. -- 2.17.1