Inline ...
________________________________ From: Alexis de Talhouët <[email protected]> Sent: Tuesday, January 9, 2018 10:40 AM To: Ramanarayanan, Karthick Cc: BRIAN D FREEMAN; [email protected] Subject: [**EXTERNAL**] Re: [onap-discuss] Failure to create the demo vfirewall VNF Hi, Please refer to https://wiki.onap.org/display/DW/ONAP+on+Kubernetes+on+Rancher+in+OpenStack<https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.onap.org_display_DW_ONAP-2Bon-2BKubernetes-2Bon-2BRancher-2Bin-2BOpenStack&d=DwMFaQ&c=06gGS5mmTNpWnXkc0ACHoA&r=3Q306Mu4iPxbTMD0vasm2o7f6Fs_R4Dsdq4HWP9yOq8&m=nhSSpq9qyfVrRqRw6aGAqAvQkaYQpNeoqFCoNmTOtGA&s=Y1p0bXPNmUj2USEO3iMzMSxeZ_0GCyZSumtYszxlwaE&e=> for setting up OOM on Kubernetes, on Racnher, in OpenStack. Please discard the update wrt DCAE (I said it’s merge, but not just yet). Yes. It was using that doc, the rancher, k8s setup was brought up for onap. I have to check back on DCAE and running it without dcae on k8s again though! Regards, -Karthick And please refer to https://wiki.onap.org/display/DW/vFWCL+instantiation%2C+testing%2C+and+debuging<https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.onap.org_display_DW_vFWCL-2Binstantiation-2C-2Btesting-2C-2Band-2Bdebuging&d=DwMFaQ&c=06gGS5mmTNpWnXkc0ACHoA&r=3Q306Mu4iPxbTMD0vasm2o7f6Fs_R4Dsdq4HWP9yOq8&m=nhSSpq9qyfVrRqRw6aGAqAvQkaYQpNeoqFCoNmTOtGA&s=vlqoBTwjKDPKZkk1e_KDSOX76mCerT0EooAevm7kJcI&e=> for running vFWCL use case. Of course, without DCAE, you won’t have close loop. Thanks, Alexis On Jan 9, 2018, at 1:36 PM, Ramanarayanan, Karthick <[email protected]<mailto:[email protected]>> wrote: Yes. I checked at sdnc pods, vnf pods, mso pods. Found nothing pertaining to the error. A sample sdnc pod check (apart from other pods) kubectl -n onap-sdnc -c sdnc-controller-container logs sdnc-1395102659-w48gp Now I have to redo this test again as I am running out of memory here. Note that this is a 14 core(28 threads for 56 total in cpuinfo), 128 gig ram. (Intel Xeon E5-2683 v3) Before I ran the OOM, I had /proc/sys/vm/drop_caches done to just start with a free memory of over 120 gigs. (After clearing the kernel buffer caches for a big head start for ONAP :) Then the kubernetes setup to relaunch onap/rancher,etc. These have been up for over 3-4 days now and now my free memory is almost down to 30 gig on the caches side. Free memory minus caches is a meagre 800 megs. Now suddenly the portals are unresponsive. The sdc frontend has stopped responding with gateway timeouts though I am fire a curl sdc2/rest/version to the backend. Frontend is dead! Its a cluster fuck now. I will restart the onap setup again before redoing the demo vfwcl instance create. (also with delete rollback set to false during vf create as Marco suggested) Hopefully you have tested a demo instance creation on a k8s setup with OOM on amsterdam. (not with ONAP running on openstack as the demo video shows) Thanks, -Karthick ________________________________ From: FREEMAN, BRIAN D <[email protected]<mailto:[email protected]>> Sent: Tuesday, January 9, 2018 5:41:48 AM To: Ramanarayanan, Karthick; [email protected]<mailto:[email protected]> Subject: [**EXTERNAL**] RE: Failure to create the demo vfirewall VNF You need to look at SO logs for the SdncAdapter and VnfAdapter and see what error you are getting from SDNC or Openstack in SO. Usually a delete implies that SO talks to SDNC correctly but then the interaction with Openstack fails or when SO goes to SDNC or AAI for data to create the Openstack heat stack create that it is failing. Brian From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Ramanarayanan, Karthick Sent: Monday, January 08, 2018 6:33 PM To: [email protected]<mailto:[email protected]> Subject: [onap-discuss] Failure to create the demo vfirewall VNF Hi, I am trying to instantiate the demo vfirewall-vsink service instance based on the video here: https://wiki.onap.org/display/DW/Running+the+ONAP+Demos?preview=/1015891/16010290/vFW_closed_loop.mp4#RunningtheONAPDemos-VNFOnboarding,Instantiation,andClosed-loopOperations<https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.onap.org_display_DW_Running-2Bthe-2BONAP-2BDemos-3Fpreview-3D_1015891_16010290_vFW-5Fclosed-5Floop.mp4-23RunningtheONAPDemos-2DVNFOnboarding-2CInstantiation-2CandClosed-2DloopOperations&d=DwMFAw&c=LFYZ-o9_HUMeMTSQicvjIg&r=e3d1ehx3DI5AoMgDmi2Fzw&m=VTydHcis8-MU0ztKmrS3--wrND4fGUtoupQgN4GyHZg&s=sHFlwt9oUg4ii_TV8umfzXphNLbVnoPEvv0hj8YTj7s&e=> While I am able to move ahead and reach till the vf create step, the add VF step for both vfirewall and packet gen instance results in failure and moves to pending delete. (sdnc preload checkbox enabled) The setup I have is OOM configured for kubernetes. I am on amsterdam release branch for OOM. So its not using openstack heat templates to instantiate ONAP. Rather just a single node configured with k8s oneclick. The difference in the video pertains to running demo-k8s.sh init from oom/kubernetes/robot to instantiate the customer models and services after copying the demo/heat to kubernetes robot /share directory for the distribute the work. The demo vfirewall closed loop service seems to be distributed as seen in the ONAP portal. ( I have also tried redistributing) I am trying to instantiate the service for demo vFWCL. Logs indicate nothing in sdnc after the vF create failure. I don't see any requests hitting Openstack logs either. The VNF preload operation seems to have succeeded for the firewall closed loop instances. The VNF profiles are also present in sdnc. I get back a http success (status code 200) with the request id as expected. A subsequent GET request for vnf topology information preloaded also works. Doing a POST using sdnc api (port 8282) works for the vnf topology preload step. But I see nothing in the logs for sdnc pods. (nothing relevant in sdc/mso pod either if that matters) Here is a snippet from curl to sdnc as well: curl -vX POST http://admin:[email protected]:8282/restconf/operations/VNF-API:preload-vnf-topology-operation<https://urldefense.proofpoint.com/v2/url?u=http-3A__admin-3AKp8bJ4SXszM0WXlhak3eHlcse2gAw84vaoGGmJvUy2U-4010.43.172.252-3A8282_restconf_operations_VNF-2DAPI-3Apreload-2Dvnf-2Dtopology-2Doperation&d=DwQFAw&c=LFYZ-o9_HUMeMTSQicvjIg&r=e3d1ehx3DI5AoMgDmi2Fzw&m=VTydHcis8-MU0ztKmrS3--wrND4fGUtoupQgN4GyHZg&s=Y3ruJ6Ym6EbR64sGaBOkI3m5Zw_Jgydl8PWX83NzX58&e=> -d @firewall.json --header "Content-Type: application/json" Response status is http 200 as expected. { "output": { "svc-request-id": "robot12", "response-code": "200", "ack-final-indicator": "Y" } } Trying to do a get request for the vnf topology preload information POST request above also returns expected information: curl -sSL http://admin:[email protected]:8282/restconf/config/VNF-API:preload-vnfs/vnf-preload-list/vfirewall-1/3d6f8762Fea8453fBd9a..base_vfw..module-0/preload-data/vnf-topology-information/vnf-topology-identifier<https://urldefense.proofpoint.com/v2/url?u=http-3A__admin-3AKp8bJ4SXszM0WXlhak3eHlcse2gAw84vaoGGmJvUy2U-4010.43.172.252-3A8282_restconf_config_VNF-2DAPI-3Apreload-2Dvnfs_vnf-2Dpreload-2Dlist_vfirewall-2D1_3d6f8762Fea8453fBd9a..base-5Fvfw..module-2D0_preload-2Ddata_vnf-2Dtopology-2Dinformation_vnf-2Dtopology-2Didentifier&d=DwQFAw&c=LFYZ-o9_HUMeMTSQicvjIg&r=e3d1ehx3DI5AoMgDmi2Fzw&m=VTydHcis8-MU0ztKmrS3--wrND4fGUtoupQgN4GyHZg&s=B-rVkAB1IjmgsV0NyrefoQR6XTfJmsEwekYrrdqmw-0&e=> | jq . { "vnf-topology-identifier": { "vnf-name": "vfirewall-1", "generic-vnf-type": "3d6f8762-fea8-453f-bd9a 0", "generic-vnf-name": "firewall-vnf", "vnf-type": "3d6f8762Fea8453fBd9a..base_vfw..module-0", "service-type": "5b5c134c-662e-407e-bc4c-4200b4b5cb02" } } I am also attaching the firewall.json POST request for vnf toplogy preload to sdnc portal. The VNF profiles have all been added to sdnc portal for the 2 vfs. But still VF create request (for both vfirewall sink and packetgen) results in failure and moves transaction to pending delete. No api request traces in Openstack as well and neither do I see any volume creates for the vnf instance. Also once in pending delete, I cannot delete the instance as well. I am also enclosing the firewall POST json request for one of the vfirewall vnfs that was preloaded to sdnc vnf topology information as a POST. (mentioned above) Attaching it inline to this mail -- { "input": { "vnf-topology-information": { "vnf-topology-identifier": { "service-type": "5b5c134c-662e-407e-bc4c-4200b4b5cb02", "vnf-name": "vfirewall-1", "vnf-type": "3d6f8762Fea8453fBd9a..base_vfw..module-0", "generic-vnf-name": "firewall-vnf", "generic-vnf-type": "3d6f8762-fea8-453f-bd9a 0" }, "vnf-assignments": { "availability-zones": [], "vnf-networks": [], "vnf-vms": [] }, "vnf-parameters": [ { "vnf-parameter-name": "image_name", "vnf-parameter-value": "Ubuntu_14.04.5_LTS" }, { "vnf-parameter-name": "flavor_name", "vnf-parameter-value": "m1.small" }, { "vnf-parameter-name": "public_net_id", "vnf-parameter-value": "aff52391-359f-4264-9768-1948c83021bc" }, { "vnf-parameter-name": "unprotected_private_net_id", "vnf-parameter-value": "zdfw1fwl01_unprotected" }, { "vnf-parameter-name": "unprotected_private_subnet_id", "vnf-parameter-value": "zdfw1fwl01_unprotected_sub" }, { "vnf-parameter-name": "protected_private_net_id", "vnf-parameter-value": "zdfw1fwl01_protected" }, { "vnf-parameter-name": "protected_private_subnet_id", "vnf-parameter-value": "zdfw1fwl01_protected_sub" }, { "vnf-parameter-name": "onap_private_net_id", "vnf-parameter-value": "private" }, { "vnf-parameter-name": "onap_private_subnet_id", "vnf-parameter-value": "private" }, { "vnf-parameter-name": "unprotected_private_net_cidr", "vnf-parameter-value": "192.168.10.0/24" }, { "vnf-parameter-name": "protected_private_net_cidr", "vnf-parameter-value": "192.168.20.0/24" }, { "vnf-parameter-name": "onap_private_net_cidr", "vnf-parameter-value": "10.0.0.0/26" }, { "vnf-parameter-name": "vfw_private_ip_0", "vnf-parameter-value": "192.168.10.100" }, { "vnf-parameter-name": "vfw_private_ip_1", "vnf-parameter-value": "192.168.20.100" }, { "vnf-parameter-name": "vfw_private_ip_2", "vnf-parameter-value": "10.0.80.1" }, { "vnf-parameter-name": "vpg_private_ip_0", "vnf-parameter-value": "192.168.10.200" }, { "vnf-parameter-name": "vsn_private_ip_0", "vnf-parameter-value": "192.168.20.250" }, { "vnf-parameter-name": "vsn_private_ip_1", "vnf-parameter-value": "10.0.80.3" }, { "vnf-parameter-name": "vfw_name_0", "vnf-parameter-value": "firewall-vnf" }, { "vnf-parameter-name": "vsn_name_0", "vnf-parameter-value": "zdfw1fwl01snk01" }, { "vnf-parameter-name": "vnf_id", "vnf-parameter-value": "vFirewall_demo_app" }, { "vnf-parameter-name": "vf_module_id", "vnf-parameter-value": "vFirewall" }, { "vnf-parameter-name": "dcae_collector_ip", "vnf-parameter-value": "10.12.5.43" }, { "vnf-parameter-name": "dcae_collector_port", "vnf-parameter-value": "8080" }, { "vnf-parameter-name": "repo_url_blob", "vnf-parameter-value": "https://nexus.onap.org/content/sites/raw";<https://urldefense.proofpoint.com/v2/url?u=https-3A__nexus.onap.org_content_sites_raw-2522&d=DwQFAw&c=LFYZ-o9_HUMeMTSQicvjIg&r=e3d1ehx3DI5AoMgDmi2Fzw&m=VTydHcis8-MU0ztKmrS3--wrND4fGUtoupQgN4GyHZg&s=P4WBio88RnHEfEvlF_G2WT-Dh21S_b_qX2LQ79fl1o4&e=> }, { "vnf-parameter-name": "repo_url_artifacts", "vnf-parameter-value": "https://nexus.onap.org/content/groups/staging";<https://urldefense.proofpoint.com/v2/url?u=https-3A__nexus.onap.org_content_groups_staging-2522&d=DwQFAw&c=LFYZ-o9_HUMeMTSQicvjIg&r=e3d1ehx3DI5AoMgDmi2Fzw&m=VTydHcis8-MU0ztKmrS3--wrND4fGUtoupQgN4GyHZg&s=ABp99a6s6ZVKW3Av2Wn2iGXnEcQkwIhMcuDCKy_ho-Q&e=> }, { "vnf-parameter-name": "demo_artifacts_version", "vnf-parameter-value": "1.1.0" }, { "vnf-parameter-name": "install_script_version", "vnf-parameter-value": "1.1.0-SNAPSHOT" }, { "vnf-parameter-name": "key_name", "vnf-parameter-value": "vfw_key" }, { "vnf-parameter-name": "pub_key", "vnf-parameter-value": "ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCfceovbVaHzy/aU2kGQjFl77zKTtacnY0I77RFf6QYM6OctBuhYt1zQt2ba4P7VBprLWdygd7a5XXBdEnDaPmDhUvfSZ0sJY/vuOLHM3WKs2QRHr1XYL3Bw7wlXLYghk2TLAyFqsMwl56IsZf0sxN1B4OjNGphwlIw6S+ppZ9eefJlIAc4ibPoXshKlZ5Sda7PzMQLZCeGPgWvFe/WUhtH10qQmUwZ7LU5YCjR4BnvnyEAQqTi4Mov5jguBwN0XP4gT35S/vRr8ollaWdsOFDkYOPiBQ9+t6z6TdKXsB29LJFxgug0AuW3Ens1s7YebmxLIr+3K0aITe3i9MUzvVb3 kramanar@PEM-KRAMANAR-01" }, { "vnf-parameter-name": "cloud_env", "vnf-parameter-value": "openstack" } ] }, "request-information": { "request-id": "robot12", "order-version": "1", "notification-url": "openecomp.org<https://urldefense.proofpoint.com/v2/url?u=http-3A__openecomp.org&d=DwMFaQ&c=06gGS5mmTNpWnXkc0ACHoA&r=3Q306Mu4iPxbTMD0vasm2o7f6Fs_R4Dsdq4HWP9yOq8&m=nhSSpq9qyfVrRqRw6aGAqAvQkaYQpNeoqFCoNmTOtGA&s=p6_8qYWInj6f2yuTT7xCPxT4ie6pE6BGWIz61YTV4t8&e=>", "order-number": "1", "request-action": "PreloadVNFRequest" }, "sdnc-request-header": { "svc-request-id": "robot12", "svc-notification-url": "http:\/\/openecomp.org:8080<https://urldefense.proofpoint.com/v2/url?u=http-3A__openecomp.org-3A8080&d=DwMFaQ&c=06gGS5mmTNpWnXkc0ACHoA&r=3Q306Mu4iPxbTMD0vasm2o7f6Fs_R4Dsdq4HWP9yOq8&m=nhSSpq9qyfVrRqRw6aGAqAvQkaYQpNeoqFCoNmTOtGA&s=Yi4ouRYvEtnS6hmoG01Ba0t3u0mm__uAencE3vVhYyE&e=>\/adapters\/rest\/SDNCNotify", "svc-action": "reserve" } } } Regards, -Karthick _______________________________________________ onap-discuss mailing list [email protected]<mailto:[email protected]> https://lists.onap.org/mailman/listinfo/onap-discuss<https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.onap.org_mailman_listinfo_onap-2Ddiscuss&d=DwMFaQ&c=06gGS5mmTNpWnXkc0ACHoA&r=3Q306Mu4iPxbTMD0vasm2o7f6Fs_R4Dsdq4HWP9yOq8&m=nhSSpq9qyfVrRqRw6aGAqAvQkaYQpNeoqFCoNmTOtGA&s=CugzksDVYR-QnlLnr5rJKVi27pypQze-Idsyn-K8X5U&e=>
_______________________________________________ onap-discuss mailing list [email protected] https://lists.onap.org/mailman/listinfo/onap-discuss
