Aniello,
1. This is one of the limitations of the current approach, until we get CDS working at full speed throughout the different phases of the use case. The reconfiguration action requires the user to pass a JSON path to the VNF topology in SDNC, which SO uses to find the appropriate values of those parameters. As you can see, the JSON path refers to array locations. Apparently the JSON path is pointing to different locations of the array, this is why you get wrong parameters. Use http://{{sdnc_ip}}:{{sdnc_port}}/restconf/config/GENERIC-RESOURCE-API:services/service/1f965bbb-9cb8-474e-a52a-d355c3251924/service-data/vnfs/vnf/1fd4c91d-d02e-4f68-a117-b44fd4a31dab/vnf-data/vf-modules/vf-module/6c24d10b-ece8-4d02-ab98-be283b17cdd3/vf-module-data/vf-module-topology/<http://%7b%7bsdnc_ip%7d%7d:%7b%7bsdnc_port%7d%7d/restconf/config/GENERIC-RESOURCE-API:services/service/1f965bbb-9cb8-474e-a52a-d355c3251924/service-data/vnfs/vnf/1fd4c91d-d02e-4f68-a117-b44fd4a31dab/vnf-data/vf-modules/vf-module/6c24d10b-ece8-4d02-ab98-be283b17cdd3/vf-module-data/vf-module-topology/> (replacing service, VNF and VF module instance ID with yours) to see the VNF topology structure in SDNC and find the right location for ip_addr and oam_ip_addr. You need to set ip_addr to $.vf-module-topology.vf-module-parameters.param[X], where X is the location of vdns_int_private_ip_0, and oam_ip_addr to $.vf-module-topology.vf-module-parameters.param[Y], where Y is the location of vdns_onap_private_ip_0. We ran the use case an infinite number of time and those array locations have always been the same, so I’m a little surprise to see that it’s not working for you. Anyways, see below an example of VNF topology, you can easily map the JSON paths above to the object below. Each name:value pair is a location in the param array. In future releases we plan to totally change this approach and replace it with CDS. 2. The max_vfmodule_instance should be an upper bound on the number of instances that you can spin up, as you said. VID won’t allow you to spin up additional instances if the cap is reached. If I understand it correctly, you are using closed loop, so Policy is actually triggering the scale out workflow instead of VID. Policy may simply ignore that parameter. This is a good catch, it shouldn’t happen. We’ll look at this in Frankfurt release at this point, this is going to add some more logic to Policy. Marco { "vf-module-topology": { "onap-model-information": { "model-name": "Vloadbalancerms..dnsscaling..module-1", "model-invariant-uuid": "40edc822-3b57-4053-ba28-243b4ecc8cd1", "model-version": "1", "model-customization-uuid": "aa1a6ecd-7416-426d-9980-6f8e50169194", "model-uuid": "f3e888bc-85ed-4155-aa8b-9dc028fc2ada" }, "vf-module-parameters": { "param": [ { "name": "vlb_private_ip_2", "value": "192.168.9.111" }, { "name": "key_name", "value": "vlb_key_scaling" }, { "name": "cloud_env", "value": "openstack" }, { "name": "vlb_private_ip_1", "value": "10.0.150.1" }, { "name": "vlb_flavor_name", "value": "m1.medium" }, { "name": "vlb_private_ip_0", "value": "192.168.10.111" }, { "name": "vlb_private_net_id", "value": "zdfw1lb01_private_ms" }, { "name": "vlb_image_name", "value": "ubuntu-16-04-cloud-amd64" }, { "name": "vlb_private_net_cidr", "value": "192.168.10.0/24" }, { "name": "install_script_version", "value": "1.3.0" }, { "name": "vdns_private_ip_0", "value": "192.168.10.212" }, { "name": "demo_artifacts_version", "value": "1.3.0" }, { "name": "onap_private_net_cidr", "value": "10.0.0.0/16" }, { "name": "pub_key", "value": "ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDQXYJYYi3/OUZXUiCYWdtc7K0m5C0dJKVxPG0eI8EWZrEHYdfYe6WoTSDJCww+1qlBSpA5ac/Ba4Wn9vh+lR1vtUKkyIC/nrYb90ReUd385Glkgzrfh5HdR5y5S2cL/Frh86lAn9r6b3iWTJD8wBwXFyoe1S2nMTOIuG4RPNvfmyCTYVh8XTCCE8HPvh3xv2r4egawG1P4Q4UDwk+hDBXThY2KS8M5/8EMyxHV0ImpLbpYCTBA6KYDIRtqmgS6iKyy8v2D1aSY5mc9J0T5t9S2Gv+VZQNWQDDKNFnxqYaAo1uEoq/i1q63XC5AD3ckXb2VT6dp23BQMdDfbHyUWfJN" }, { "name": "vnf_id", "value": "vLoadBalancerMS" }, { "name": "vdns_private_ip_1", "value": "10.0.150.4" }, { "name": "onap_private_subnet_id", "value": "oam_network_Kpxe" }, { "name": "availability_zone_0", "value": "AZ1" }, { "name": "vdns_name_0", "value": "vdns-ms02-1119-1" }, { "name": "vf_module_id", "value": "vLoadBalancerMS" }, { "name": "onap_private_net_id", "value": "oam_network_Kpxe" }, { "name": "nb_api_version", "value": "1.2.0" }, { "name": "dns_enabled", "value": "true" }, { "name": "sec_group", "value": "onap_sg_Kpxe" }, { "name": "public_net_id", "value": "971040b2-7059-49dc-b220-4fab50cb2ad4" } ] }, "tenant": "ebb0ea7144004bacac1e39ff23105fa7", "sdnc-generated-cloud-resources": true, "aic-clli": "clli1", "vf-module-topology-identifier": { "vf-module-type": "Vloadbalancerms..dnsscaling..module-1", "vf-module-id": "2ed9c430-3e73-431d-8aaf-31494d6aaec5", "vf-module-name": "vLoadBalancerMS-Vnf-1119-1_1" }, "aic-cloud-region": "RegionOne", "vf-module-assignments": {} } } http://{{sdnc_ip}}:{{sdnc_port}}/restconf/config/GENERIC-RESOURCE-API:services/service/1f965bbb-9cb8-474e-a52a-d355c3251924/service-data/vnfs/vnf/1fd4c91d-d02e-4f68-a117-b44fd4a31dab/vnf-data/vf-modules/vf-module/6c24d10b-ece8-4d02-ab98-be283b17cdd3/vf-module-data/vf-module-topology/ From: <[email protected]> on behalf of Aniello Paolo Malinconico <[email protected]> Reply-To: "[email protected]" <[email protected]>, "[email protected]" <[email protected]> Date: Friday, September 13, 2019 at 9:07 AM To: "[email protected]" <[email protected]> Subject: [onap-discuss] [Dublin] VF Module Scale Out Use Case - Clarification Hi all, i am testing the VF Scale Out Use Case on Dublin enviroment. I have deployed the entire use case and the automatic closed loop works well. However, I have the following questions to clarify the use case: 1. At certain point, during the clamp operational policy configuration, I must tell to the SO the inputs passed for the vf scaling : requestParameters: '{"usePreload":false,"userParams":[]}' configurationParameters: '[{"ip-addr":"$.vf-module-topology.vf-module-parameters.param[17].value","oam-ip-addr":"$.vf-module-topology.vf-module-parameters.param[31].value"}]' But in the APPC-LCM-READ, I see this: "{\"version\":\"2.0\",\"type\":null,\"body\":{\"input\":{\"common-header\":{\"timestamp\":\"2019-09-13T09:53:45.619Z\",\"api-ver\":\"2.00\",\"originator-id\":\"MSO\",\"request-id\":\"a227abc8-425b-4f74-afdb-c6af36035178\",\"sub-request-id\":\"af652a4b-2b12-41fd-8c31-d8d8a1431268\",\"flags\":{\"mode\":\"NORMAL\",\"force\":\"FALSE\",\"ttl\":65000}},\"action\":\"ConfigScaleOut\",\"action-identifiers\":{\"vnf-id\":\"dc35df18-4695-4a25-a6a9-4f04642e9a2a\"},\"payload\":\"{\\\"request-parameters\\\":{\\\"vnf-host-ip-address\\\":\\\"10.0.101.50\\\",\\\"vf-module-id\\\":\\\"d1894567-1a9d-411e-a6a9-1fb93f4276e9\\\"},\\\"configuration-parameters\\\":{\\\"ip-addr\\\":\\\"dc35df18-4695-4a25-a6a9-4f04642e9a2a\\\",\\\"oam-ip-addr\\\":\\\"SUCCESS\\\"}}\"}},\"rpc-name\":\"config-scale-out\",\"correlation-id\":\"a227abc8-425b-4f74-afdb-c6af36035178-af652a4b-2b12-41fd-8c31-d8d8a1431268\",\"cambria.partition\":null}" The values of ip-addr and oam-ip-addr params are not what I thinked to be. I think they should contains the real ip of the new DNS instance. Isn't it? 2. At certain point, during the onboarding phase of the service, in the deployment pannel of SDC GUI, we set the vDNS param "max_vfmodule_instances" to 3. But the closed loop continues to deploy new vDNS instances even if the number of deployed vDNS instances is greater than 3. Is it an issue? Thanks a lot, Aniello Paolo Malinconico -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#18947): https://lists.onap.org/g/onap-discuss/message/18947 Mute This Topic: https://lists.onap.org/mt/34126870/21656 Group Owner: [email protected] Unsubscribe: https://lists.onap.org/g/onap-discuss/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
