The reason I asked about your openstack version is because you may be running into a heat template/heat template parameter issue where in Rocky that the allowed_address requires a cidr (a bug that I t

Kuldeep, Compare the preload data in the log.html zip file on the wiki that I referred to with your log.html results. instantiateVFWCLGRA is the one that I tested so you should compare to that preload

BTW you should be using instantiateVFWCLGRA so that you trigger the GRA API not the VNF_API https://wiki.onap.org/display/DW/2%3A+Frankfurt+Release+Integration+Testing+Status has a log.html attached f

What version of openstack are you running ? The error message form openstack HEAT indicates that it want’s a /32 on the parameter data which seems like a new behavior (if the error message is valid) B

Appc and sdnc use the same odl / ccsdk container image so that means your sdnc is sane and I’d be looking at the gNB side. Brian

#sdnc

It looks like the gNB is not emiting (!CDATA seems wrong) or accepting valid XML (hello is clearly part of the base:1.0 namespace). Have you tried connecting sdnc to a vFW just to test the netconf con

#sdnc

CDATA is strange in a hello message. Also not sure if its cut and paste but there are two <xml> header lines. Shouldn’t it look more like this ? Brian <?xml version="1.0" encoding="UTF-8"?> <hello xml

#sdnc

This seems to be popping up again. Hadn’t seen that since Beijing when we moved off the single release strategy. Did something change that the configmap is so large (or am I mis-remembering) ? Brian

Sent: Tuesday, July 14, 2020 10:53 AM To: onap-discuss@...; FREEMAN, BRIAN D <bf1936@...>; Mike Elliott <Mike.Elliott@...> Cc: Santosh Bayas <Santosh.Bayas@...>; Sumit Cha

The existing SDNC healthcheck tests the odl container and the mariadb container and agree it doesn’t test the other containers. Adding test cases is fairly easy on the robot side (robot/resources/sdnc

Also – does your openstack.rc indicate 5000 as the port that openstack is listening on ? I assume so or otherwise robot would have thrown an error but just checking. Brian

#so

Controller is the internal openstack name for the neutron controller. https://docs.openstack.org/neutron/stein/install/controller-install-rdo.html Are you running devstack or regular openstack ? Can y

#so

SO containers only support sh since they are alpine based. The mariadb tables for cloud_identity services is where the openstack url , hostname, domain etc are set. ./demo-k8s.sh onap init will set th

#so

https://docs.onap.org/projects/onap-oom/en/latest/oom_quickstart_guide.html#oom-quickstart-guide scroll down to the second integration-override.yaml file. Make sure you have the openStackKeystoneAPIVe

I would think that error in the config of the SO openstack adapter talking to neutron. What did you set the openstack credentials to in the override yaml or so helm chart or what did robot set cloud d

I posted a log file from vcpe.py on the vCPE wiki page: https://wiki.onap.org/display/DW/vCPE+Use+Case+Tutorial%3A+Design+and+Deploy+based+on+ONAP#vCPEUseCaseTutorial:DesignandDeploybasedonONAP-Checkl

Btw did you try a shorter network name ? Sent via the Samsung Galaxy S8, an AT&T 5G Evolution capable smartphone

Vcpe.py is in the intergration repository under integration/test/vcpe – there is a preload.py that does the preloads for SDNC, SNIRO and SO. The sdnc logs should be under /var/log/onap/sdnc/karaf.log

Perhaps SDNC is saving with the “ “ and SO is querying without the “ “ hence it cant find it since the network-name is used as the preload-id on the subsequence SO to SDNC query. Brian

BTW – I don’t know if this is your problem but you have a space in the network-name. There is a test in DG for a blank that you might be triggering. "network-name": " network_instance_20eeb098-6121-4e