summaryrefslogtreecommitdiffstats
path: root/docs/conf.py
diff options
context:
space:
mode:
authorDan Timoney <dtimoney@att.com>2019-05-29 18:42:58 +0000
committerGerrit Code Review <gerrit@onap.org>2019-05-29 18:42:58 +0000
commit886428da4168a9f33786153c68609e1013de35cf (patch)
treed1e0eb2d12fb600eb7e6835b0b961a9ba905c2eb /docs/conf.py
parent1faa0f9465cb70e2f625cf668df9eb81d225819c (diff)
Update git submodules
* Update docs/submodules/ccsdk/cds.git from branch 'dublin' to 2bb065a5f965087c58828a5a8b690838d63da65c - Merge "Returning null for unresolved variables" into dublin - Returning null for unresolved variables When Blueprints Processor was not able to evaluate a variable, it would set its value to null. The expected behaviour would be to set the value to the default repres- entation in the formal notation as defined by Apache Velocity, which is a dollar followed by the name of the variable between curly braces. For example, if the value of the variable pnf-id could not be evaluated in runtime, its value would be defined as the string "${pnf-id}". The problem happened during evaluation of the variables that would be later sent to the template-meshing code for processing. The fix was to add a check before the value was assigned to the varia- ble; if the was not null, the assignment will happen normally. Otherwi- se, if the evaluation resolves to null, the variable receives the defa- ult value (string "${<variable name>}"). Besides the tests that were put in place to test the code changed for this fix, two tests were added to the existing test case of the templa- te meshing code, to act as regression test. Change-Id: I635afb1eba4c0d45b821811f0119fa6c87ea9542 Issue-ID: CCSDK-1358 Signed-off-by: ottero <rodrigo.ottero@est.tech>
Diffstat (limited to 'docs/conf.py')
0 files changed, 0 insertions, 0 deletions