Page History

vCPE Use Case - Customer Service Instantiation - 171031171103.pdf

12/11

...

/2017

1. Error was returned from app-c to policy saying malformed message and schema node with name common header wasn't found. This error is caused by know issue APPC-309 vCpeResCust custom workflow: 
2. Modified the vcperescust service and then redistribution to AAI failed. It looks like SDC has a problem handling update but it is not easy to pinpoint the problem. The workaround is to recreate the service from scratch. Distribution passed.
3. Brian created the infrastructure including BNG BRG vGMUX, which are to be used for vcperescust flow.
Found a bug in TunnelXConn flow where the content send to SDNC assign is incorrect. Fixed with code change onsite. Tracked by 

Jira
server ONAP JIRA columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution serverId 425b2b0a-557c-3c0c-b515-579789cceedb key

SO

APPC-309

. The problem is fixed for Beijing release, but required a change for Amsterdam. The appc.LCM.provider.url property needs to be added to the /opt/openecomp/appc/data/properties/appc.properties file in the app_controller_container docker image.

1. Code Block
   title /opt/openecomp/appc/data/properties/appc.properties
   appc.LCM.provider.url=http://127.0.0.1:8181/restconf/operations/appc-provider-lcm

11/17/2017

1. Regression test in SB01 passed.

11/16/2017

1. Custom service instantiation succeeded in SB01 new install.

2. To do data plane test from BRG to the web server, follow the steps below

   Code Block
   collapse true
   On the vGW: # restart the dhcp server (https://gerrit.onap.org/r/24151 -should fix this once it is reviewed and merged) systemctl restart isc-dhcp-server On the vBRG: # get ip address from vGW for the lstack interface (should be something like 192.168.1.2) dhclient lstack # add route to the 10.2.0.0 network ip route add 10.2.0.0/24 via 192.168.1.254 dev lstack # finally: wget http://10.2.0.10 returns the index.html file from the web server at 10.2.0.10

11/16/2017

1. Retested all latest version of DGs in the Integration workspace and fixed all known problems.
2. Reinstalled ONAP in Integration-SB01 with the lastest build. Pass.
3. Retested service creation and distribution in SB01. Pass.
4. Retested Infrastructure service instantiation in SB01. Pass.
5. Retested customer service instantiation in SB01. Found a previous problem in SO: global-customer-id missing from tunnelxconn create and activate requests. Waiting to be fixed.

11/15/2017

1. Regression test in SB01

   1. Fix SDNC DB with the following

      Code Block
      update ALLOTTED_RESOURCE_MODEL set ecomp_generated_naming='Y',type='TunnelXConnect',allotted_resource_type='TunnelXConnect' where customization_uuid='f3ef75e8-5cb5-4c1b-9a5a-5ddcefb70b57'; update ALLOTTED_RESOURCE_MODEL set ecomp_generated_naming='Y',type='BRG',allotted_resource_type='TunnelXConnect' where customization_uuid='4c3f8585-d8a8-4fd9-bad8-87296529c4d0';

      
      

      
      

   2. Error occurred in SDNC for tunnelxconn assign due to the previous null values in AAI query

      Code Block

      2017-11-15T12:16:59.863Z, Method : GET 2017-11-15 12:16:59,864 | INFO | qtp79019442-4883 | AAIService | 300 - org.openecomp.sdnc.sli.aai - 0.1.0 | Request URL : https://aai.api.simpledemo.openecomp.org:8443/aai/v11/business/customers/customer/null/service-subscriptions/service-subscription/null/service-instances/service-instance/null/allotted-resources/allotted-resource/67986ea9-e932-4ae5-9f77-26693e103d1d 2017-11-15 12:16:59,864 | INFO | qtp79019442-4883 | AAIService | 300 - org.openecomp.sdnc.sli.aai - 0.1.0 | Missing requestID. Assigned af5b154f-fc6d-477b-bcca-6fd29cb57cf2 2017-11-15 12:16:59,920 | INFO | qtp79019442-4883 | metric | 294 - org.onap.ccsdk.sli.core.sli-common - 0.1.2 | 2017-11-15 12:16:59,920 | INFO | qtp79019442-4883 | AAIService | 300 - org.openecomp.sdnc.sli.aai - 0.1.0 | Response code : 404, Not Found 2017-11-15 12:16:59,920 | INFO | qtp79019442-4883 | AAIService | 300 - org.openecomp.sdnc.sli.aai - 0.1.0 | Response data : Entry does not exist.

      The request from SO looks good:

      Code Block

      2017-11-15T12:17:00.075Z|3b6d089c-4ac5-4d61-9d02-173616322088|MSO-RA-5212I Sending request to SDNC:RequestTunables [reqId=3b6d089c-4ac5-4d61-9d02-173616322088, msoAction=, operation=tunnelxconn-topology-operation, action=assign, reqMethod=POST, sdncUrl=http://c1.vm1.sdnc.simpledemo.openecomp.org:8282/restconf/operations/GENERIC-RESOURCE-API:tunnelxconn-topology-operation, timeout=270000, headerName=sdnc-request-header, sdncaNotificationUrl=http://c1.vm1.mso.simpledemo.openecomp.org:8080/adapters/rest/SDNCNotify, namespace=org:onap:sdnc:northbound:generic-resource] 2017-11-15T12:17:00.075Z|3b6d089c-4ac5-4d61-9d02-173616322088|SDNC Request Body: <?xml version="1.0" encoding="UTF-8"?><input xmlns="org:onap:sdnc:northbound:generic-resource"><sdnc-request-header><svc-request-id>3b6d089c-4ac5-4d61-9d02-173616322088</svc-request-id><svc-action>assign</svc-action><svc-notification-url>http://c1.vm1.mso.simpledemo.openecomp.org:8080/adapters/rest/SDNCNotify</svc-notification-url></sdnc-request-header><request-information ><request-id>2240cf26-1e38-4b0d-9d24-a27cf32c4098</request-id><request-action>CreateTunnelXConnInstance</request-action><source>MSO</source><notification-url/><order-number/><order-version/> </request-information><service-information ><service-id/><subscription-service-type>vCPE</subscription-service-type><onap-model-information/><service-instance-id>33b22c7c-aade-4c28-8f81-4ee9c223c388</service-instance-id><subscriber-name/><global-customer-id>SDN-ETHERNET-INTERNET</global-customer-id> </service-information><allotted-resource-information ><allotted-resource-id>67986ea9-e932-4ae5-9f77-26693e103d1d</allotted-resource-id><allotted-resource-type>tunnelxconn</allotted-resource-type><parent-service-instance-id>0eea37ae-c25e-4f57-93f9-e87e6b3b69ed</parent-service-instance-id><onap-model-information><model-invariant-uuid>09ebcb84-c683-48c4-8120-4318489a56d0</model-invariant-uuid><model-uuid>d0a16427-34ec-4dec-9b83-c2ec04f60525</model-uuid><model-customization-uuid>f3ef75e8-5cb5-4c1b-9a5a-5ddcefb70b57</model-customization-uuid><model-version>1.0</model-version><model-name>tunnelxconn111301</model-name> </onap-model-information> </allotted-resource-information><tunnelxconn-request-input ><brg-wan-mac-address>fa:16:3e:19:65:96</brg-wan-mac-address> </tunnelxconn-request-input></input>

   3. To configure vGMUX VES event including packet loss rate and vnfid, follow the instructions from Eric:

      Code Block

      There is a vgmux image in the ONAP-vCPE project space called: vgmux2-base-ubuntu-16-04 This one has the ability to configure the sourceName in the VES event to something different than the default value (which is the vnf-id present in the vm’s openstack metadata). Some documentation: Configuring the VES mode - via REST This will set the ‘demo’ mode and packet loss to 40%, but does ‘not’ change the sourceName: curl -i -H "Content-Type:application/json" --data '{"mode":{"working-mode":"demo","base-packet-loss":40,"source-name":""}}' -X POST -u admin:admin http://127.0.0.1:8183/restconf/config/vesagent:vesagent Delete the config in order to change it via REST: curl -i -H "Content-Type:application/json" -X DELETE -u admin:admin http://127.0.0.1:8183/restconf/config/vesagent:vesagent/mode curl -i -H "Content-Type:application/json" --data '{"mode":{"working-mode":"demo","base-packet-loss":88,"source-name":"testing-123-ABC"}}' -X POST -u admin:admin http://127.0.0.1:8183/restconf/config/vesagent:vesagent Configuring the VES mode - via CLI QUERY: # vppctl show ves mode Mode Base Packet Loss Rate Source Name Demo 88.0% testing-123-ABC SET: vppctl set ves mode demo base 77 source hello-there This sets the sourceName to “hello-there” Leave off the 'source <name>' arguments to set back to default (i.e. vnf-id from openstack metadata)

11/14/2017

1. Regression test in SB01
   1. SO API handler dropped source from VID request, causing error in BPMN. Fixed. See 

      Jira
      server ONAP JIRA columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution serverId 425b2b0a-557c-3c0c-b515-579789cceedb key SO-340

   2. SO has cannot pass AAI authentication. The problem is that AAI replaced the old cert (exp 11/30/2017) with a new one (exp dec. 2018). The solution is to use the CA in SO. 
      1. In SO docker, find aai.crt, replace the content with this ca_bundle_for_openecomp.txt (which includes both root and intermediate CA).
      2. run "update-ca-certificates -f"
      3. restart SO docker.

   3. SO failed to query AAI cloud region, the problem is the default config in /etc/mso/config.d/mso.bpmn.urn.properties. The correct lines are below. 

      Jira
      server ONAP JIRA columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution serverId 425b2b0a-557c-3c0c-b515-579789cceedb key SO-343

      Code Block
      collapse true
      mso.workflow.default.aai.v11.tenant.uri=/aai/v11/cloud-infrastructure/cloud-regions/cloud-region/CloudOwner/RegionOne/tenants/tenant mso.workflow.default.aai.v11.cloud-region.uri=/aai/v11/cloud-infrastructure/cloud-regions/cloud-region/CloudOwner mso.workflow.default.aai.v11.cloud-region.uri=/aai/v11/cloud-infrastructure/cloud-regions/cloud-region/CloudOwner

   4. Preloading works!
   5. Successfully created infrastructure!

11/11/2017

1. Regression test in SB01

   1. An ONAP based on the latest build was installed on 11/12. Need to go to appc_vm and change /opt/config/docker_version.txt: 1.1-STAGING-latest to 1.2-STAGING-latest.

   2. Onboarding, service design, service distribution completed in SB01.
   3. SO does not add recipe automatically. Manual insertion was done.
   4. SDNC does not insert correct data to its DB. Tracked by 

      Jira
      server ONAP JIRA columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution serverId 425b2b0a-557c-3c0c-b515-579789cceedb key SDNC-194

      1. For ALLOTTED_RESOURCE_MODEL, BRG and TunnelXConn do not have 'Y' for its ecomp_generated_naming. Their types are "VF", and their 'allotted resource type' fields are null.
      2. VF_MODEL is good.
      3. SERVICE_MODEL is good.
      4. VF_MODULE_MODEL is good.
   5. VID has a problem to create services. Tracked by 

      Jira
      server ONAP JIRA columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution serverId 425b2b0a-557c-3c0c-b515-579789cceedb key VID-91

      
      
      
2. vCpeResCust custom workflow:

   1. Jim fixed xml parsing problem for service delete and now the flow can pick up vgw, tunnelxconn AR, and vbrg AR from the service info returned from AAI. An error was captured when SO requests SDNC for brg deactivate. The request to SDNC is below

      
      

      Code Block
      collapse true
      <sdncadapterworkflow:SDNCAdapterWorkflowRequest xmlns:ns5="http://org.openecomp/mso/request/types/v1" xmlns:sdncadapterworkflow="http://org.openecomp/mso/workflow/schema/v1" xmlns:sdncadapter="http://org.openecomp/workflow/sdnc/adapter/schema/v1"> <sdncadapter:RequestHeader> <sdncadapter:RequestId>b6106b00-b9f1-418c-9dc3-aca97664cd05</sdncadapter:RequestId> <sdncadapter:SvcInstanceId>41235b16-5c38-4c29-82e9-6784d9decf46</sdncadapter:SvcInstanceId> <sdncadapter:SvcAction>deactivate</sdncadapter:SvcAction> <sdncadapter:SvcOperation>brg-topology-operation</sdncadapter:SvcOperation> <sdncadapter:CallbackUrl>http://mso:8080/mso/SDNCAdapterCallbackService</sdncadapter:CallbackUrl> </sdncadapter:RequestHeader> <sdncadapterworkflow:SDNCRequestData> <request-information> <request-id>2ba02fea-7a07-4641-87fb-abb10a305b44</request-id> <request-action>DeleteBRGInstance</request-action> <source>MSO</source> <notification-url/> <order-number/> <order-version/> </request-information> <service-information> <service-id></service-id> <subscription-service-type>vCPE</subscription-service-type> <onap-model-information></onap-model-information> <service-instance-id>41235b16-5c38-4c29-82e9-6784d9decf46</service-instance-id> <subscriber-name/> <global-customer-id>SDN-ETHERNET-INTERNET</global-customer-id> </service-information> <allotted-resource-information> <allotted-resource-id>99dc7978-3efe-4074-805c-2ae5dc785c88</allotted-resource-id> <allotted-resource-type>brg</allotted-resource-type> <parent-service-instance-id>e565bb6b-de14-4a5c-a992-65a681771a7a</parent-service-instance-id> <onap-model-information> <model-invariant-uuid></model-invariant-uuid> <model-uuid></model-uuid> <model-customization-uuid></model-customization-uuid> <model-version></model-version> <model-name></model-name> </onap-model-information> </allotted-resource-information> <brg-request-input> </brg-request-input> </sdncadapterworkflow:SDNCRequestData> </sdncadapterworkflow:SDNCAdapterWorkflowRequest>

      The AAI request from SDNC is below. Note that a few values are 'null'

      Code Block

      2017-11-13 17:07:01,916 | INFO | SvcLogicGraph [module=GENERIC-RESOURCE-API, rpc=brg-topology-operation-deactivate, mode=sync, version=1.2.0-SNAPSHOT] | Request URL : https://aai.api.simpledemo.openecomp.org:8443/aai/v11/business/customers/customer/null/service-subscriptions/service-subscription/null/service-instances/service-instance/null/allotted-resources/allotted-resource/99dc7978-3efe-4074-805c-2ae5dc785c88

11/10/2017

1. vCpeResCust custom workflow:
   1. Brian made changes on the SDNC side. Now SDNC can pass a list of parameters to SO for vG assign call. Then SO passes those parameters to HEAT to instantiate vG.
   2. Jim fixed the DoDeleteVfModule flow to use generic-resource-api and construct the corresponding request body when performing SDNC deactivate call. Note that the flow checks the configuration variable sdncversion to determine what request body to construct. This is something not fully understood by the team.
   3. Delete of vG succeeded.
   4. Jim continues to work on 

      Jira
      server ONAP JIRA columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution serverId 425b2b0a-557c-3c0c-b515-579789cceedb key SO-325

      .

   5. Eric has modified vGMUX to add a workaround, see below:
      
      

      Code Block
      title vGMUX set sourceName collapse true
      There is a vgmux image in the ONAP-vCPE project space called: vgmux2-base-ubuntu-16-04 This one has the ability to configure the sourceName in the VES event to something different than the default value (which is the vnf-id present in the vm’s openstack metadata). Some documentation: Configuring the VES mode - via REST This will set the ‘demo’ mode and packet loss to 40%, but does ‘not’ change the sourceName: curl -i -H "Content-Type:application/json" --data '{"mode":{"working-mode":"demo","base-packet-loss":40,"source-name":""}}' -X POST -u admin:admin http://127.0.0.1:8183/restconf/config/vesagent:vesagent Delete the config in order to change it via REST: curl -i -H "Content-Type:application/json" -X DELETE -u admin:admin http://127.0.0.1:8183/restconf/config/vesagent:vesagent/mode curl -i -H "Content-Type:application/json" --data '{"mode":{"working-mode":"demo","base-packet-loss":88,"source-name":"testing-123-ABC"}}' -X POST -u admin:admin http://127.0.0.1:8183/restconf/config/vesagent:vesagent Configuring the VES mode - via CLI QUERY: # vppctl show ves mode Mode Base Packet Loss Rate Source Name Demo 88.0% testing-123-ABC SET: vppctl set ves mode demo base 77 source hello-there This sets the sourceName to “hello-there” Leave off the 'source <name>' arguments to set back to default (i.e. vnf-id from openstack metadata) Sample event with an overwritten sourceName: { "event": { "commonEventHeader": { "domain": "measurementsForVfScaling", "eventId": "Generic_traffic", "eventName": "Measurement_vGMUX", "eventType": "HTTP request rate", "lastEpochMicrosec": 1510347222243201, "priority": "Normal", "reportingEntityId": "No UUID available", "reportingEntityName": "zdcpe1cpe01mux01", "sequence": 23, "sourceId": "vCPE_Infrastructure_vGMUX_demo_app", "sourceName": "testing-123-ABC", "startEpochMicrosec": 1510347212243201, "version": 1.2 }, "measurementsForVfScalingFields": { "additionalMeasurements": [ { "arrayOfFields": [ { "name": "Packet-Loss-Rate", "value": "88.0" } ], "name": "ONAP-DCAE" } ], "cpuUsageArray": [ { "cpuIdentifier": "cpu1", "cpuIdle": 100.0, "cpuUsageSystem": 0.0, "cpuUsageUser": 0.0, "percentUsage": 0.0 } ], "measurementInterval": 10, "measurementsForVfScalingVersion": 2.1, "requestRate": 2567, "vNicUsageArray": [ { "receivedOctetsDelta": 0.0, "receivedTotalPacketsDelta": 0.0, "transmittedOctetsDelta": 0.0, "transmittedTotalPacketsDelta": 0.0, "vNicIdentifier": "eth0", "valuesAreSuspect": "true" } ] } } }

11/9/2017

1. vCpeResCust custom workflow:
   1. Closed loop: manually send VES event to DCAE, APPC successfully restarted VNF via two options: directly talking to Openstack, calling MultiCloud API.
      
      1. To restart through Openstack, we need the following vserver info in AAI. This is added by heat bridge. Note that if identity-url is missing then APPC will use the default one from its properties. 

         
         

         Code Block
         "vserver-selflink": "http://10.12.25.2:8774/v2.1/466979b815b5415ba14ada713e6e1846/servers/9e17027d-c09d-45c4-9a7a-84f50a2246fd",

      2. In the appc container, /opt/openecomp/appc/data/properties/appc.properties should have either of the following lines.

         Code Block
         provider1.identity=http://10.12.25.2:5000/v3 #this is for openstack provider1.identity=http://10.0.14.1:9005/api/multicloud-titanium_cloud/v0/pod25_RegionOne/identity/v2.0 #this is for multicloud

         
         

         
         

      3. To restart through MultiCloud, the following ESR should be added, note that the identity-url and  the vserver self link is pointing to MultiCloud. Note that the vserver selflink has a different IP and port. APPC picks up the user name and password from ESR and use them to access MultiCloud API.

         Code Block
         title ESR and vserver data from AAI collapse true
         https://aai1:8443/aai/v11/cloud-infrastructure/cloud-regions/cloud-region/CloudOwner/RegionOne?depth=all { "cloud-owner": "CloudOwner", "cloud-region-id": "RegionOne", "cloud-type": "SharedNode", "owner-defined-type": "OwnerType", "cloud-region-version": "v1", "identity-url": "http://10.0.14.1:9005/api/multicloud-titanium_cloud/v0/pod25_RegionOne/identity/v3", "cloud-zone": "CloudZone", "sriov-automation": false, "resource-version": "1510239649440", "tenants": { "tenant": [ { "tenant-id": "466979b815b5415ba14ada713e6e1846", "tenant-name": "Integration", "resource-version": "1509709609665", "vservers": { "vserver": [ { "vserver-id": "9e17027d-c09d-45c4-9a7a-84f50a2246fd", "vserver-name": "zdcpe1cpe01dns01_110306", "vserver-name2": "zdcpe1cpe01dns01_110306", "prov-status": "ACTIVE", "vserver-selflink": "http://10.0.14.1:80/v2.1/466979b815b5415ba14ada713e6e1846/servers/9e17027d-c09d-45c4-9a7a-84f50a2246fd", "in-maint": false, "is-closed-loop-disabled": false, "resource-version": "1510183808208", .... "esr-system-info-list": { "esr-system-info": [ { "esr-system-info-id": "432ac032-e996-41f2-84ed-9c7a1766eb29", "system-name": "example-system-name-val-29070", "type": "example-type-val-85254", "vendor": "example-vendor-val-94515", "version": "example-version-val-71880", "service-url": "http://10.12.25.2:5000/v3", "user-name": "demo", "password": "onapdemo", "system-type": "VIM", "ssl-cacert": "example-ssl-cacert-val-75021", "ssl-insecure": true, "ip-address": "example-ip-address-val-44431", "port": "example-port-val-93234", "cloud-domain": "Default", "default-tenant": "Integration", "resource-version": "1510239649503" } ] } }

   2. Tested DeleteVcpeResCust flow.
      1. After a few bug fixes, the flow was able to delete the vG stack. But the subsequent SDNC request returned an error: 

         Jira
         server ONAP JIRA columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution serverId 425b2b0a-557c-3c0c-b515-579789cceedb key SDNC-184

         .
      2. The flow failed to pick up allotted resources: 

         Jira
         server ONAP JIRA columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution serverId 425b2b0a-557c-3c0c-b515-579789cceedb key SO-325

11/8/2017

1. vCpeResCust custom workflow:
   1. Successfully passed custom workflow test: created tunnelxconn-allotted-resource, vG, brg-allotted-resourece, configured vGMUX and vBRG. Note that currently VxLAN on vG is manually configured.
   2. Task: DG change to configure vG VxLAN: 

      Jira
      server ONAP JIRA columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution serverId 425b2b0a-557c-3c0c-b515-579789cceedb key SDNC-182

   3. Task: DG change to return the following vG heat parameters to SO. This is in vfmodule assign.

      Code Block
      title vG heat parameters to be returned by SDNC collapse true
      mux_gw_private_net_id: zdfw1muxgw01_private mux_gw_private_subnet_id: zdfw1muxgw01_sub_private mux_gw_private_net_cidr: 10.5.0.0/24 cpe_public_net_id: vCPEInfraCPEPUBLIC110306 cpe_public_subnet_id: vCPEInfraCPEPUBLICSUB110306 cpe_public_net_cidr: 10.2.0.0/24 onap_private_net_id: oam_onap_hUnI onap_private_subnet_id: oam_onap_hUnI onap_private_net_cidr: 10.0.0.0/16 vgw_private_ip_0: 10.5.0.22 vgw_private_ip_1: 10.0.101.30 vgw_private_ip_2: 10.2.0.2 vgw_name_0: zdcpe1cpe01gw01 vnf_id: vCPE_Infrastructure_GW_demo_app vf_module_id: vCPE_Customer_GW mux_ip_addr: 10.5.0.21 vg_vgmux_tunnel_vni: 100

   4. Brian will fix the HEAT bridge in robot, which will be used to add vserver info to AAI.
   5. Brian will add a DHCP server in the Webserver.

11/7/2017

1. vCpeResCust custom workflow:
   1. SO configuration update needed: 

      Jira
      server ONAP JIRA columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution serverId 425b2b0a-557c-3c0c-b515-579789cceedb key SO-315

      , 

      Jira
      server ONAP JIRA columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution serverId 425b2b0a-557c-3c0c-b515-579789cceedb key SO-278

      .
   2. Distribution of updated service from SDC to SO problem identified: 

      Jira
      server ONAP JIRA columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution serverId 425b2b0a-557c-3c0c-b515-579789cceedb key SO-316

      .
   3. vG heat template updated with two more parameters added in env and yml. Image also updated.
   4. vGMux heat updated.
   5. Error in SDNC on brg-allocated-resource activate. Will fix by Wed.
2. Closed loop:
   1. vServer data is missing from AAI. May need to add manually.
   2. VES data reporting from vGMUX had incorrect sourceName, need to be updated.

11/6/2017

1. vCpeResCust custom workflow:
   1. Test almost finished. Successfully created tunnel-x-connect, vG, and brg-allotted-resource. When SO finally queries SDC with the parent service instance id of brg-allotted-resource (which is the service instance id of vbrg service), SDNC failed to find it in its catalog. This will be fixed. Once this query passes, SO service flow will finish successfully.
   2. SO calling SDNC to create a vG instance failed. SDNC queried AAI to find the availability zone but such a zone did not exist. Brian fixed this by manually adding such a zone and a complex in AAI. Jerry will add this in demo.sh init. 

      1. Add an availability zone

         Code Block
         title Add availability zone collapse true
         https://aai1:8443/aai/v11/cloud-infrastructure/cloud-regions/cloud-region/CloudOwner/RegionOne/availability-zones/availability-zone/nova { "availability-zone-name": "nova", "hypervisor-type": "KVM", "operational-status": "Active" }

      2. Add an complex

         Code Block
         title Add a complex collapse true
         https://aai1:8443//aai/v11/cloud-infrastructure/complexes/complex/clli1 { "physical-location-id": "clli1", "data-center-code": "example-data-center-code-val-5556", "complex-name": "clli1", "identity-url": "example-identity-url-val-56898", "resource-version": "1509928831089", "physical-location-type": "example-physical-location-type-val-7608", "street1": "example-street1-val-34205", "street2": "example-street2-val-99210", "city": "example-city-val-27150", "state": "example-state-val-59487", "postal-code": "example-postal-code-val-68871", "country": "example-country-val-94173", "region": "example-region-val-13893", "latitude": "example-latitude-val-89101", "longitude": "example-longitude-val-66229", "elevation": "example-elevation-val-30253", "lata": "example-lata-val-46073" }

      3. Add relationship in CloudOwner to the above complex

         Code Block
         title Add relationship to the complex collapse true
         https://aai1:8443/aai/v11/cloud-infrastructure/cloud-regions/cloud-region/CloudOwner/RegionOne/ Do a GET of CloudOwner/RegionOne and add this relationship then do a PUT back to CloudOwner/RegionOne "relationship": [ { "related-to": "complex", "related-link": "/aai/v11/cloud-infrastructure/complexes/complex/clli1" } Example: { "cloud-owner": "CloudOwner", "cloud-region-id": "RegionOne", "cloud-type": "SharedNode", "owner-defined-type": "OwnerType", "cloud-region-version": "v1", "cloud-zone": "CloudZone", "sriov-automation": false, "resource-version": "1509931173816", "relationship-list": { "relationship": [ { "related-to": "complex", "related-link": "/aai/v11/cloud-infrastructure/complexes/complex/clli1" }, { "related-to": "l3-network", .... more data ...

   3. SO calling SDNC during vG instantiation used incorrect format for vG. What defined in Yang uses dash, e.g., vg-ip. SO used vg_ip. SO fixed this onsite.
   4. vG instantiation completed successfully. Currently the IP address facing vGMUX is using the one in HEAT. SO workflow should take the one allocated by SDNC. 
   5. SO: preProcessSDNCAssign workflow didn't include modelCustomizationUuid. This was fixed onsite.

   6. A routing entry needs to be added to the SDNC VM (not docker) to allow reaching BRG through BNG:

      Code Block
      ip route add 10.3.0.0/24 via 10.0.101.10 dev eth0

   7. SDNC assign of brg-allotted-resource failed. Note that unassign, activate, deactive all may have similar problems.
      1. The original DG had an error and was not loaded to SDNC. Fixed.
      2. The assign DG didn't set global-customer-id. Fixed.
      3. The assign DG didn't set service instance uuid. Fixed.
   8. The latest config for SO are: mso.sdnc.properties and mso.bpmn.urn.properties. Note that these config files are dynamically generated when SO docker container is started/restarted. After the latest fixes, there should be no need to use these files anymore.

11/4/2017

1. vCpeResCust custom workflow: 

   1. Postman body to invoke SO updated

      Code Block
      language java title to invoke SO collapse true
      http://so:8080/ecomp/mso/infra/serviceInstances/v5 user/pass: InfraPortalClient:password1$ Content-Type and Accept are both: application/json { "requestDetails" : { "requestInfo" : { "productFamilyId" : "a9a77d5a-123e-4ca2-9eb9-0b015d2ee0fb", "suppressRollback" : "false", "instanceName" : "vcperescust-1104-19", "requestorId": "Kang", "source" : "Postman-Kang" }, "requestParameters" : { "subscriptionServiceType" : "vCPE", "userParams" : [{ "name":"BRG_WAN_MAC_Address", "value":"fa:16:3e:8f:ea:68" }], "aLaCarte" : "false" }, "subscriberInfo" : { "subscriberName" : "Kaneohe", "globalSubscriberId" : "SDN-ETHERNET-INTERNET" }, "cloudConfiguration" : { "lcpCloudRegionId" : "RegionOne", "tenantId" : "466979b815b5415ba14ada713e6e1846" }, "modelInfo" : { "modelType" : "service", "modelVersionId" : "2da136af-510d-457e-b3dc-f1c3e6dab0c3", "modelName" : "vCpeResCust110403", "modelVersion" : "1.0", "modelInvariantId" : "35f93cd5-17a8-4735-9531-a63df867d776" } } }

   2. Made much progress by modifying multiple DGs with temp fixes. Marcus is working to fix them the right way and commit to the repo. Passed TunnelXConn steps: assign, create. Wait to be tested: activate. Some of the problems are:
      1. Incorrect username/password for authentication;
      2. Correct username/password in configuration file, but they are referenced incorrectly in DG.
      3. DG does not obtain globalcustomerID and gmux service ID properly, and thus failed to query AAI.
      4. Use incorrect IP to config vGMUX.
      5. Restconf request to vGMUX has mal-formatted body.
      6. DG has error (use incorrect resource) when allocating IP addresses for vG.
   3. Created a new vCpeResCust110403 service. The difference is that now the vG model is based on the latest heat and env: vgw.zip. The heat and env have been validated using openstack stack create. Note that in order to correctly distribute to SO, all the components were created from scratch, including vG (from onboarding), tunnelXconn VF, vBRG Allotted Resource VF. After distribution, added service recipe in SO DB and allotted resources to SDNC DB. Verified that this service model can be executed through SO API.

11/3/2017

1. vCpeResCust custom workflow: 

   1. Modified the vcperescust service and then redistribution to AAI failed. It looks like SDC has a problem handling update but it is not easy to pinpoint the problem. The workaround is to recreate the service from scratch. Distribution passed.

   2. Brian created the infrastructure including BNG BRG vGMUX, which are to be used for vcperescust flow.

   3. Found a bug in TunnelXConn flow where the content send to SDNC assign is incorrect. Fixed with code change onsite. Tracked by 

      Jira
      server ONAP JIRA columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution serverId 425b2b0a-557c-3c0c-b515-579789cceedb key SO-302

   4. Found a few missing configurations and mistakes in mso.sdnc.properties, fixed onsite. The file being used now is mso.sdnc.properties.

   5. Found a problem in SDNC handling TunnelXConn create operation. Dan fixed it onsite. 

   6. TunnelXConn flow has a bug: the SDNC assign request misses some info: 

      Jira
      server ONAP JIRA columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution serverId 425b2b0a-557c-3c0c-b515-579789cceedb key SO-304

   7. SDNC ueb cannot parse service template when distributed. Reopen this ticket: 

      Jira
      server ONAP JIRA columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution serverId 425b2b0a-557c-3c0c-b515-579789cceedb key SDC-564

      .

   8. Manually inserted the following into SDNC DB tables:

      Code Block
      title Insert into sdnc db ALLOTTED_RESOURCE_MODEL collapse true
      INSERT INTO SERVICE_MODEL (`service_uuid`, `model_yaml`,`invariant_uuid`,`version`,`name`,`description`,`type`,`category`,`ecomp_naming`,`service_instance_name_prefix`,`filename`,`naming_policy`) values ('467676e2-bcd9-4bf5-b9fd-03afea76be17', null, '4f90a895-d9f5-472c-8f65-afc5ca28628d',null,'vCPEService', 'vCPEService', 'Service','Network L1-3', 'N', 'vCPEService', 'vCpeResCust110602/service-Vcperescust110602-template.yml',null); INSERT INTO ALLOTTED_RESOURCE_MODEL (`customization_uuid`,`model_yaml`,`invariant_uuid`,`uuid`,`version`,`naming_policy`,`ecomp_generated_naming`,`depending_service`,`role`,`type`,`service_dependency`,`allotted_resource_type`) VALUES ( '48e00a09-4184-4689-b690-3baabaf24838', NULL, 'a99d5de7-0707-4f4c-b7b5-f92101ce9ddc', '4fb476c3-3516-4433-8300-47690e48ea5c', '1.0', NULL,'Y',NULL,NULL,'TunnelXConnect',NULL, 'TunnelXConnect'); INSERT INTO ALLOTTED_RESOURCE_MODEL (`customization_uuid`,`model_yaml`,`invariant_uuid`,`uuid`,`version`,`naming_policy`,`ecomp_generated_naming`,`depending_service`,`role`,`type`,`service_dependency`,`allotted_resource_type`) VALUES ( '0f2d8c72-6470-42cf-9b2f-f30041ffc78d', NULL, '8415033a-3c4c-4de5-b38f-3e31be32ddf2', '33094f6f-d19f-451f-b307-201b18400a45', '1.0', NULL,'Y',NULL,NULL,'BRG',NULL, 'TunnelXConnect'); INSERT INTO VF

   302
   9. Found a few missing configurations and mistakes in mso.sdnc.properties, fixed onsite. The file being used now is mso.sdnc.properties.
   10. Found a problem in SDNC handling TunnelXConn create operation. Dan fixed it onsite. 
   11. SDNC ueb cannot parse service template when distributed. Reopen this ticket: 

       Jira
       server ONAP JIRA columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution serverId 425b2b0a-557c-3c0c-b515-579789cceedb key SDC-564

       .

   12. Manually inserted the following into table: ALLOTTED_RESOURCE_MODEL

       Code Block
       title Insert into sdnc db ALLOTTED_RESOURCE_MODEL collapse true
       INSERT INTO ALLOTTED_RESOURCE_MODEL (`customization_uuid`,`model_yaml`,`invariant_uuid`,`uuid`,`version`,`name`,`naming_policy`,`ecomp_generated_naming`,`depending_service`,`role`,`type`,`service_dependency`,`allotted_resource_type`) `avail_zone_max_count`,`nf_function`,`nf_code`,`nf_type`,`nf_role`,`vendor`,`vendor_version`) VALUES ( 'ab20868702f251be-8cbf3941-43684c4d-80e39510-a6e9f17ccd1a71f6cc620e41', NULL, '19ec7776b7773de9-50feb4af-49154593-bc999802-cda08306583a1d7512f8fa38', '470567017e53fec2-dc628032-4f0d43c0-840fb41c-f93f31424b15ad3f564f42d4', '1.0', 'vgw-kang-110602',NULL,'Y',1,NULL,NULL,NULL,NULL,'TunnelXConnectvCPE',NULL, 'TunnelXConnect'1.0'); INSERT INTO ALLOTTEDVF_RESOURCEMODULE_MODEL (`customization_uuid`,`model_yaml`,`invariant_uuid`,`uuid`,`version`,`naming`vf_module_policy`type`,`ecomp`availability_generatedzone_naming`count`,`depending_service`,`role`,`type`,`service_dependency`,`allotted_resource_type`)`ecomp_generated_vm_assignments`) VALUES ( '9ad2424ffeac8fbd-a18f7de0-4f544b84-8ef7a194-f3326584c1da98b1ab6e4750', NULL, '73f307f554d3bef4-b9f548be-4fd847e1-90d88529-25d703d1cfadda2a160f40a9', '76c0f51ceaf47c0a-4760287f-42124d5f-99d0a8f7-9bbcb08fdc11f608ac4d4aae', '1.0', 'Base',NULL,NULL,NULL,NULL,'TunnelXConnect',NULL, 'TunnelXConnect'); );

   13. A few other tickets: 

       Jira
       server ONAP JIRA columns key,summary,status maximumIssues 20 jqlQuery key in (SDNC-170,SDNC-169,SDNC-168,SDNC-167) serverId 425b2b0a-557c-3c0c-b515-579789cceedb

11/2/2017

1. vCpeResCust custom workflow: 
   1. vcperescust service failed to distribute from SDC to SO for several reasons:
      1. For the vBRG EMU allotted resource, we first designed it using "Allotted Resource" subcategory, SO did not accept it. We then re-designed it using "Tunnel XConn" subcategory, SO accepted it. But it is not clear if this will cause problem later on.
      2. Each VF in the service is assigned a customizationUUID. That ID is not changed unless the VF is removed and recreated in SDC composition. SO throws an error if a service being redistributed includes a component with the same customizationUUID. Basically it checks the DB to see if the ID already exist, if yes then reports a duplicate customizationUUID error in /var/log/ecomp/MSO/ASDC.../msodebug.log. If we need to change and redistribute a service, the workaround is to delete each component and add back in.
      3. Solutions:
         1. We recreated the mso container and db container to start with empty DB tables. Note that only recreate the DB does not work as it will lack the camunda records, which are created when the mso container is initialized.
         2. To recreate, delete the mso container, change /opt/test_lab/deploy.sh to enable "--force-recreate mariadb". Remember to turn it back off afterwards.
         3. After new mso container is created, do the following.
            1. Run cpjars to copy the updated jar and war files into the docker. This is not needed if docker is updated.
            2. Restart the container to load the above files.
            3. Run cpproperties to copy the properties in mso.bpmn.urn.properties, mso.sdnc.properties. Note that this properties got reset each time the container is restarted. This is not needed once docker is updated. But to enable debug log for specific items, some of the flags in mso.bpmn.urn.properties are still needed.
   2. SNIRO is updated to meet the needs of the Homing query. Now the data to be loaded to SNIRO is this (updated 11/7): sniro.json. Note that some of the contents needs to be updated, such as gmux uuid.
   3. To clear the sniro content: GET http://robot:8080/__admin/mappings/reset
   4. To check sniro logs: docker logs -f sniroemulator
   5. TunnelXConn flow queried AAI using the vCpeResCust service instance uuid but got nothing. This was caused by racing condition: it was too soon to query after the service flow put the same uuid in AAI. The temp solution is to let the flow sleep for 30 seconds before performing query. It worked. Note that sleeping for 5 seconds was proven to be insufficient.

...

1. vCpeResCust custom workflow: 

   1. Use the following to add the custom workflow into the recipe table:

      Code Block
      title insert into recipe collapse true
      INSERT INTO `service_recipe` (`ACTION`, `VERSION_STR`, `DESCRIPTION`, `ORCHESTRATION_URI`, `SERVICE_PARAM_XSD`, `RECIPE_TIMEOUT`, `SERVICE_TIMEOUT_INTERIM`, `CREATION_TIMESTAMP`, `SERVICE_MODEL_UUID`) VALUES ('createInstance','1','vCpeRestCust110301','/mso/async/services/CreateVcpeResCustService',NULL,181,NULL,'2017-11-03 13:48:00','b12d36da-459f-41be-aadc-7034568690eb');

   2. Successfully invoked the custom workflow from SO NBI using curl (note that VID currently only support a la carte so cannot invoke this flow). 

      Code Block
      title invoke vCpeResCust workflow collapse true
      curl -X POST \ http://so:8080/ecomp/mso/infra/serviceInstances/v5 \ -H 'accept: application/json' \ -H 'authorization: Basic SW5mcmFQb3J0YWxDbGllbnQ6cGFzc3dvcmQxJA==' \ -H 'cache-control: no-cache' \ -H 'content-type: application/json' \ -H 'postman-token: 0c4f0ea7-736f-4999-3399-982de75ceecf' \ -d '{ "requestDetails" : { "requestInfo" : { "productFamilyId" : "a9a77d5a-123e-4ca2-9eb9-0b015d2ee0fb", "suppressRollback" : "false", "instanceName" : "vcperescust-102404", "requestorId": "demo", "source" : "VID" }, "requestParameters" : { "subscriptionServiceType" : "123456789", "userParams" : [{ "name":"BRG_WAN_MAC_Address", "value":"brgmac" }], "aLaCarte" : "false" }, "subscriberInfo" : { "subscriberName" : "Kaneohe", "globalSubscriberId" : "SDN-ETHERNET-INTERNET" }, "cloudConfiguration" : { "lcpCloudRegionId" : "RegionOne", "tenantId" : "466979b815b5415ba14ada713e6e1846" }, "modelInfo" : { "modelType" : "service", "modelVersionId" : "ASDC_TOSCA_UUID", "modelName" : "vCpeResCust", "modelVersion" : "1.0", "modelInvariantId" : "1963dd8b-9375-4cab-aa59-0ee06e8333fa" } } } '

   3. A bug is discovered for the workflow and is being worked on (tracked by 

      Jira
      server ONAP JIRA columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution serverId 425b2b0a-557c-3c0c-b515-579789cceedb key SO-262

      .
2. Genera Infrastructure: With the following manual fix we are able to distribute the service to SO.

   1. The generic neutron network HEAT template is missing from the SO DB. Brian found a way to manually fix it. SO will include this in the repo. It is tracked by 

      Jira
      server ONAP JIRA columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution serverId 425b2b0a-557c-3c0c-b515-579789cceedb key SO-265

      . The scipt and heat template are given below (updated on 10/25 based on Brian Freeman's comments to 

      Jira
      server ONAP JIRA columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution serverId 425b2b0a-557c-3c0c-b515-579789cceedb key SO-265

      ).

      Code Block
      title insert HEAT into SO DB collapse true
      INSERT INTO `heat_template_params` (`HEAT_TEMPLATE_ARTIFACT_UUID`,`PARAM_NAME`,`IS_REQUIRED`,`PARAM_TYPE`,`PARAM_ALIAS` ) VALUES ('efee1d84-b8ec-11e7-abc4-cec278b6b50a','network_name',1 ,'string', NULL); INSERT INTO `heat_template_params` (`HEAT_TEMPLATE_ARTIFACT_UUID`,`PARAM_NAME`,`IS_REQUIRED`,`PARAM_TYPE`,`PARAM_ALIAS` ) VALUES ('efee1d84-b8ec-11e7-abc4-cec278b6b50a','shared',0 ,'string', NULL); INSERT INTO `heat_template` (`ARTIFACT_UUID`, `NAME`,`VERSION` , `BODY`, `TIMEOUT_MINUTES`,`DESCRIPTION`, `CREATION_TIMESTAMP`, `ARTIFACT_CHECKSUM` ) VALUES ('efee1d84-b8ec-11e7-abc4-cec278b6b50a', 'GenericNeutronNetGeneric NeutronNet', '1', LOAD_FILE('/tmp/generic_neutron.yaml') , 10 ,'Generic Neutron Template',NOW(), 'MANUAL RECORD'); heat_template_version: 2013-05-23 description: A simple Neutron network parameters: network_name: type: string description: Name of the Neutron Network default: ONAP-NW1 shared: type: boolean description: Shared amongst tenants default: True outputs: network_id: description: Openstack network identifier value: { get_resource: network } resources: network: type: OS::Neutron::Net properties: name: { get_param: network_name } shared: { get_param: shared }

   2. network_resource table model_invariant_uuid was too short (20 instead of at least 36). Manually increased to 120. It is tracked by 

      Jira
      server ONAP JIRA columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution serverId 425b2b0a-557c-3c0c-b515-579789cceedb key SO-266

3. Genera Infrastructure: Instantiation
   
   1. Need to run "/opt/demo.sh init" in the robot VM first.
   2. A service was created using VID.
   3. Tried to add a neutron network to it. SO received an error from SDNC. This is tracked by 

      Jira
      server ONAP JIRA columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution serverId 425b2b0a-557c-3c0c-b515-579789cceedb key SDNC-143

   4. The 404 error in VID on deploy is due to missing zone data in AAI. Preload AAI with the following:

      Code Block
      title Preload AAI with zone data collapse true
      PUT https://{{aai}}:8443/aai/v11/network/zones/zone/nova1 { "zone-id": "nova1", "zone-name": "nova", "design-type": "integration", "zone-context": "labs", "status": "Active" }

4. VNFs:
   1. Updated doc is available: ONAP vCPE VPP-based VNF Installation and Usage Information
5. Closed loop: APPC-MultiCloud:
   1. The team is debugging the API request from APPC to MultiCloud. It is tracked by 

      Jira
      server ONAP JIRA columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution serverId 425b2b0a-557c-3c0c-b515-579789cceedb key MULTICLOUD-119

...