Error when requesting map_package_on_service function from tnglib

[efotopoulou]

robot test fails on map_package_on_service function when called from /test_runtime_policy_lifecycle/test.robot file

This is the output as seen at command line after test execution:

==============================================================================
Test :: Test suite for enforcing a Runtime Policy to the SP platform          
==============================================================================
Setting the SP Path                                                   | PASS |
------------------------------------------------------------------------------
Upload the Package                                                    | FAIL |
KeyError: 'name'

Can we fix this? Am i requesting correctly the map_package_on_service funtion? Thanks in advance :-)

[tsoenen]

Method takes a package uuid as argument and returns a service uuid. Just checked it locally and seems to work correctly.

Could be an issue with the package. Which env and what is the package uuid?

[efotopoulou]

first of all, Thank you very much for you quick response! :-)

well i created a very short test with the package uuid hardcoded:

*** Settings ***
Documentation     Test suite for enforcing a Runtime Policy to the SP platform
Library           tnglib

*** Variables ***
${HOST}                http://int-sp-ath.5gtango.eu   #  the name of SP we want to use
${PACKAGE_UUID}        1270f101-44c1-418c-bc39-58e6b65e611a        

*** Test Cases ***
Setting the SP Path
    Set SP Path     ${HOST}
    ${result} =     Sp Health Check
    Should Be True   ${result}
Upload the Package
    ${service} =     Map Package On Service  ${PACKAGE_UUID}
    Should Be True     ${service[0]}
    Set Suite Variable     ${SERVICE_UUID}  ${service[1]}
    Log     ${SERVICE_UUID}

i get the same error! i also pull all latest tng-cli updates today.... Are you able to run the above small test ?

==============================================================================
Test :: Test suite for enforcing a Runtime Policy to the SP platform          
==============================================================================
Setting the SP Path                                                   | PASS |
------------------------------------------------------------------------------
Upload the Package                                                    | FAIL |
KeyError: 'name'
------------------------------------------------------------------------------
Test :: Test suite for enforcing a Runtime Policy to the SP platform  | FAIL |
2 critical tests, 1 passed, 1 failed
2 tests total, 1 passed, 1 failed
==============================================================================

[tsoenen]

I'm getting the same error. Seems that the nsd of the package you are using doesn't have the 'name' key.

[tsoenen]

When requesting the nsds, the payload of the response is wrong for the nsd of your package.

created_at: '2019-06-24T12:08:05.513+00:00'
md5: 4d53b4ef04e35720e719900331a20a32
nsd:
  nsd-catalog:
    nsd:
      constituent-vnfd:

It shouldn't have the nsd-catalog nesting. Either a GK issue or a package issue.

[efotopoulou]

i am using the eu.5gtango.ns-squid-haproxy.0.1.tgo package from y1 demo. Do we have an updated version of this specific NS??

I could also base my tests on the test-nsid1v NS for homogeneity reasons (i saw that you use this for testing scaling out/in functionality) The only problem is that test-nsid1v NS does not have monitoring_parameters or snmp_parameters as the ns-squid-haproxy and i need them so as to enable specific monitoring rules for the alerts.

Can we enhance the test-nsid1v with monitoring metrics or get an updated version of squid-haproxy service?

[tsoenen]

I don't have a strong opinion on which of the two options to go with. Either way should work I guess.

[efotopoulou]

For me is the same. i would opt for the more quick one. Did you create the test-nsid1v service? if yes can you add some dummy monitoring metrics such as:

monitoring_parameters:
  - name: "cpu_util"
    unit: "Percentage"
  - name: "memory_usage"
    unit: "MB"

i can also do it.... not sure if i have to change something more within the package.

About the squid-haproxy NS not sure what i have to change... NS name seems to be there.... https://github.com/sonata-nfv/tng-y1-demo/blob/master/tango/squid-haproxy/Definitions/ns-squid-haproxy.yaml#L5

[tsoenen]

The squid-haproxy issue is not the nsd itself, it is the payload formatting when requesting the nsd from the GTK. You could check with Jose why the formatting is unexpected. Should be an easy fix.

You can add monitoring parameters as you want to the test-sdi1v service. I think Panos is the guy to ask if you have doubts there.

[efotopoulou]

i think i will try to solve the squid-haproxy case. Is the test-nsid1v horizontally scalable? have you tested that? if not maybe i will come up with more issues while creating the policies integrated tests.

One last thing....at the portal is see that the squid-haproxy service is correctly fetched as service.... https://int-sp-ath.5gtango.eu/service-platform/network-services/1d09d884-a418-4129-add3-b936e6b5bd17

I do not understand what to ask at Jose for. If the payload formatting was malformed then it would not be available neither from the portal. right? Which API you requested at so as to get the wrong response?

When requesting the nsds, the payload of the response is wrong for the nsd of your package.

created_at: '2019-06-24T12:08:05.513+00:00'
md5: 4d53b4ef04e35720e719900331a20a32
nsd:
  nsd-catalog:
    nsd:
      constituent-vnfd:

It shouldn't have the nsd-catalog nesting. Either a GK issue or a package issue.

Thanks again in advance!

[tsoenen]

curl http://int-sp-ath.5gtango.eu:32002/api/v3/services | jq .

there is a different in nesting for your nsd. No idea why this works on the portal.

[efotopoulou]

Different nesting seems to be related with the platform (5gtango or osm). ns-squid-haproxy NA is saved as an osm package within the 5gtango portal "platform": "osm"

the .tgo i submit should be saved at portal as 5gtango package.

i will follow up the conversation at gitter so as to come up with a solution in collaboration with gatekeeper.

Thanks a lot for the guidance! :-)