Date   
Re: VF Module Scale Out Use Case - questions about closed-loop chain.

Marco Platania
 

Policy doesn’t execute closed loop for each received event. For a given event, Policy runs one closed loop every X minutes, this is why the VNF is locked. At the expiration of the timeout (lock), the closed loop is executed again. I can’t remember where locks are kept, Jorge can help with that. Guard policies are pushed by the user from CLAMP typically (unless you call Policy API directly), so they do what the user tells them to do. Note however that for scale out, Policy doesn’t call APPC, it calls SO (which later on calls APPC for VNF health check and reconfiguration). I’m not sure whether your configuration reflects this. You shouldn’t expect Policy to publish in APPC-LCM-READ.

 

Marco

 

From: Ferrero Marco Angelo <marco.ferrero@...>
Date: Monday, September 2, 2019 at 11:13 AM
To: "onap-discuss@..." <onap-discuss@...>, "PLATANIA, MARCO (MARCO)" <platania@...>, "PLATANIA, MARCO (MARCO)" <platania@...>, "HERNANDEZ-HERRERO, JORGE" <jh1730@...>
Cc: "Malinconico Aniello Paolo <a.malinconico@...> (a.malinconico@...)" <a.malinconico@...>, D'Alessandro Alessandro Gerardo <alessandro.dalessandro@...>, Signorelli Marco <marco.signorelli@...>
Subject: VF Module Scale Out Use Case - questions about closed-loop chain.

 

Hi everybody,

 

We are testing the VF Module Scale Out use case.

 

Our vLB correctly sends data to the VES Collector and it correctly publishes data on DMaaP topic unauthenticated.VES_MEASUREMENT_OUTPUT.

TCA correctly read data from this topic and, as the threshold is violated, correctly publishes data on DMAAP topic unauthenticated.DCAE_CL_OUTPUT

Policy Drools read data from this topic and applies frequency guard but it does not propagate the event even if it seems send evets to DMaap topic POLICY-CL-MGT

Who consumes messages from this topic (POLICY-CL-MGT) and who writes to topic APPC-LCM-READ in order to propagate the commands to the APPC ?

 

Accessing to network.log file of policy drools we have found the following messages :

 

[2019-08-31T00:37:54.089+00:00|Session org.onap.policy.drools-applications.controlloop.common:controller-usecases:1.4.2:usecases][OUT|

{

  "AAI": {

    "vserver.prov-status": "ACTIVE",

    "vserver.resource-version": "1566468980498",

    "vserver.is-closed-loop-disabled": "false",

    "vserver.vserver-name2": "RegionOne_ONAP-NF_20190821T135252709Z_vlb_001",

    "vserver.vserver-id": "ccadfb9d-0386-43d5-b007-887ec9ce3fcc",

    "vserver.vserver-selflink": "http://163.162.95.137:8774/v2.1/a9d84b4e2c1e47bfaa4d26d2d894c9c2/servers/ccadfb9d-0386-43d5-b007-887e

    "vserver.in-maint": "false",

    "vserver.vserver-name": "RegionOne_ONAP-NF_20190821T135252709Z_vlb_001"

  },

  "closedLoopAlarmStart": 1567211854626801,

  "closedLoopControlName": "LOOP_vLoadBalancer_20190821_v1_0_vLoadBalancer_201908210_k8s-tca-clamp-policy",

  "version": "1.0.2",

  "requestId": "2d530ae5-cdc5-41a3-83fe-0166431d26e7",

  "closedLoopEventClient": "DCAE_INSTANCE_ID.dcae-tca",

  "targetType": "VM",

  "target": "vserver.vserver-name",

  "from": "policy:usecases",

  "policyScope": "onap.policies.controlloop.Operational:1.0.0",

  "policyName": "OPERATIONAL_vLoadBalancer_20190821_v1_0_vLoadBalancer_201908210_k8s-tca-clamp-policy.EVENT.MANAGER",

  "policyVersion": "1.0.0",

  "notification": "REJECTED",

  "message": "The target RegionOne_ONAP-NF_20190821T135252709Z_vlb_001 is already locked",

  "notificationTime": "2019-08-31 00:37:54.089000+00:00",

  "history": []

}

[2019-08-31T00:38:08.124+00:00|qtp1534754611-39]10.42.10.195 - - [31/Aug/2019:00:38:08 +0000] "GET /healthcheck HTTP/1.1" 200 102

root@cp-1:~/oom/kubernetes# 00|qtp1534754611-35]10.42.10.195 - - [31/Aug/2019:00:38:23 +0000] "GET /healthcheck HTTP/1.1" 200 102

 

It seems that we vserver entry in the AAI  (vserver relative to the vLB) is locked ?

Why it is locked ?

Who locks it ?

Where are kept the locks ?

 

I have also accessed the policy db

 

root@dev-policy-policydb-868884d57f-g4h9g:/# mysql -uroot -psecret

Welcome to the MariaDB monitor.  Commands end with ; or \g.

Your MariaDB connection id is 776820

Server version: 10.2.14-MariaDB-10.2.14+maria~jessie mariadb.org binary distribution

 

Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others.

 

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

 

MariaDB [(none)]> show databases;

+---------------------+

| Database            |

+---------------------+

| information_schema  |

| log                 |

| migration           |

| mysql               |

| onap_sdk            |

| operationshistory   |

| operationshistory10 |

| performance_schema  |

| policyadmin         |

| pooling             |

| support             |

+---------------------+

11 rows in set (0.02 sec)

 

And I have checked the operationhistory schema :

 

I made the resume query

 

MariaDB [operationshistory]> select count(*),message from operationshistory group by message;

+----------+---------------------------+

| count(*) | message                   |

+----------+---------------------------+

|     1474 | 999 Failed                |

|    11411 | Operation denied by Guard |

+----------+---------------------------+

2 rows in set (0.03 sec)

 

And I always got ‘999 Failed’ every time the guard let it me execute the policy.

Who send this code ?

Where I can get the log of the policy executor that generate this message ?

 

Thank you in advance for your precious help,

 

Marco Ferrero

 

 

------------------------------------------------------------------
TIM

Marco Angelo Ferrero
Mobile & Fixed Innovation
IP, Transport & Core Innovation

TIM S.p.A.
Via G. Reiss Romoli, 274 – 10148 TORINO
+39 011 2286739
+39 331 6001354

 

Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie.

This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks.

Rispetta l'ambiente. Non stampare questa mail se non è necessario.

 

[Dublin] Error while instantiating a service

Aniello Paolo Malinconico
 

Hi all,
I have onboarded the vDNS use case via SDC GUI on ONAP Dublin deployment.
But when I try to instantiate it via Postman (MACRO Instantation) , it fails returning the following error:

Error from SDNC: vnf-information.onap-model-information.model-customization-uuid is a required input"

I have found this error in the past too, and I was able to resolve it by re-distributing the service. But now, after redistributing it for 4 times, it still fails.
How can I solve it? Do I need to open a Jira ticket?
In this last example, I have created a new service containing an old-VF used for old services. Can the VFs be shared among several services?

Thanks,
Aniello Paolo Malinconico

Re: vCPE usecase: DHCP issue

Michal Ptacek
 

Hi Brian,

 

sure, we plan to do that (hopefully this week)

 

Best regards,

Michal

 

From: FREEMAN, BRIAN D <bf1936@...>
Sent: Wednesday, August 28, 2019 6:43 PM
To: m.ptacek@...; onap-discuss@...; eric.w.multanen@...; stephen.gooch@...; Bin.Yang@...; Eddy.Raineri@...
Cc: morgan.richomme@...; PLATANIA, MARCO <platania@...>; 'Bartlomiej Grzybowski' <b.grzybowski@...>
Subject: RE: [onap-discuss] vCPE usecase: DHCP issue

 

Michal,

 

Could I ask you to update the vCPE page on pre-conditions to high light the problems you are finding in the environment for this as well ?

 

Brian

 

 

From: m.ptacek@... <m.ptacek@...>
Sent: Wednesday, August 28, 2019 10:22 AM
To: onap-discuss@...; m.ptacek@...; eric.w.multanen@...; FREEMAN, BRIAN D <bf1936@...>; stephen.gooch@...; Bin.Yang@...; Eddy.Raineri@...
Cc: morgan.richomme@...; PLATANIA, MARCO <platania@...>; 'Bartlomiej Grzybowski' <b.grzybowski@...>
Subject: RE: [onap-discuss] vCPE usecase: DHCP issue

 

We made some progress in the analysis. It looks the problem is in our infra (Openstack w linuxbridges)

 

BRG_BNG network is configured under following bridge:

 

[root@ONAP-6 ~]# brctl show brqefdfa895-c3

bridge name     bridge id               STP enabled     interfaces

brqefdfa895-c3          8000.801844e5d3a5       no              em2.1047

                                                                                                    tap26dcf061-45

                                                                                                    tap543b0a2f-95

 

we see DHCP requests coming from BRG side

 

[root@ONAP-6 ~]# tcpdump -i tap26dcf061-45

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode

listening on tap26dcf061-45, link-type EN10MB (Ethernet), capture size 262144 bytes

15:15:42.522172 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from fa:16:3e:9d:1c:ac (oui Unknown), length 284

15:15:47.522313 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from fa:16:3e:9d:1c:ac (oui Unknown), length 284

 

and also DHCP offers (replies) are coming from BNG

 

[root@ONAP-6 ~]# tcpdump -i tap543b0a2f-95

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode

listening on tap543b0a2f-95, link-type EN10MB (Ethernet), capture size 262144 bytes

15:16:42.522923 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from fa:16:3e:9d:1c:ac (oui Unknown), length 284

15:16:42.525320 IP 10.3.0.1.bootps > 255.255.255.255.bootpc: BOOTP/DHCP, Reply, length 290

15:16:48.522944 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from fa:16:3e:9d:1c:ac (oui Unknown), length 284

15:16:48.525152 IP 10.3.0.1.bootps > 255.255.255.255.bootpc: BOOTP/DHCP, Reply, length 290

 

however they are dropped by kernel on bridge as „traffic from Mars“

 

Aug 28 15:05:48 ONAP-6 kernel: IPv4: martian source 255.255.255.255 from 10.3.0.1, on dev brqefdfa895-c3

Aug 28 15:05:48 ONAP-6 kernel: ll header: 00000000: ff ff ff ff ff ff fa 16 3e 80 b2 a1 08 00        ........>.....

Aug 28 15:05:53 ONAP-6 kernel: IPv4: martian source 255.255.255.255 from 10.3.0.1, on dev brqefdfa895-c3

Aug 28 15:05:53 ONAP-6 kernel: ll header: 00000000: ff ff ff ff ff ff fa 16 3e 80 b2 a1 08 00        ........>.....

 

I think it’s because that 10.3.0.x network looks not to be „local“ for that interface or bridge

 

brqefdfa895-c3: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500

        ether 80:18:44:e5:d3:a5  txqueuelen 1000  (Ethernet)

        RX packets 926  bytes 291684 (284.8 KiB)

        RX errors 0  dropped 0  overruns 0  frame 0

        TX packets 0  bytes 0 (0.0 B)

        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

 

[root@ONAP-6 ~]# ifconfig em2.1047

em2.1047: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500

        ether 80:18:44:e5:d3:a5  txqueuelen 1000  (Ethernet)

        RX packets 0  bytes 0 (0.0 B)

        RX errors 0  dropped 0  overruns 0  frame 0

        TX packets 465  bytes 151590 (148.0 KiB)

        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

 

[root@ONAP-6 ~]# ifconfig tap26dcf061-45

tap26dcf061-45: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500

        inet6 fe80::fc16:3eff:fe9d:1cac  prefixlen 64  scopeid 0x20<link>

        ether fe:16:3e:9d:1c:ac  txqueuelen 1000  (Ethernet)

        RX packets 467  bytes 152242 (148.6 KiB)

        RX errors 0  dropped 0  overruns 0  frame 0

        TX packets 8  bytes 648 (648.0 B)

        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

 

[root@ONAP-6 ~]# ifconfig tap543b0a2f-95

tap543b0a2f-95: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500

        inet6 fe80::fc16:3eff:fe80:b2a1  prefixlen 64  scopeid 0x20<link>

        ether fe:16:3e:80:b2:a1  txqueuelen 1000  (Ethernet)

        RX packets 466  bytes 154712 (151.0 KiB)

        RX errors 0  dropped 0  overruns 0  frame 0

        TX packets 476  bytes 153216 (149.6 KiB)

        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

 

so it’s infra issue, most likely not visible in windriver lab if there is OVS L2 agent in there …..

 

we need to dig deeper ….

 

M.

 

From: onap-discuss@... <onap-discuss@...> On Behalf Of Michal Ptacek via Lists.Onap.Org
Sent: Tuesday, August 27, 2019 10:27 PM
To: onap-discuss@...; eric.w.multanen@...; 'FREEMAN, BRIAN D' <bf1936@...>; stephen.gooch@...; Bin.Yang@...; Eddy.Raineri@...
Cc: morgan.richomme@...; 'PLATANIA, MARCO' <platania@...>; 'Bartlomiej Grzybowski' <b.grzybowski@...>
Subject: Re: [onap-discuss] vCPE usecase: DHCP issue

 

Just a few updates:

 

  • change of demo scripts from 1.4.0 to 1.5.0-SNAPSHOT (integration lab version) did not bring any change

 

  • if I enable DHCP agent in Openstack for vcpe_net_brg_bng_201908271954 network,

VPP on BRG will get IP from neutron dhcp agent (so it looks it just simply dont buy that forwarded DHCP offer via  Option 82)

 

root@zdcpe1cpe01brgemu01-201908271954:~# vppctl show int addr

GigabitEthernet0/4/0 (up):

  10.3.0.5/24

local0 (dn):

tap-0 (up):

  l2 bridge bd_id 10 shg 0

tap-1 (up):

  20.0.0.40/24

 

(no MAC address visible in mariadb for SDNC)

 

 

  • with disabled DHCP agent traffic capturing outside of VPP layer (pcaps I already shared) is a bit tricky, as openstack is not creating network namespace for that (if there is no DHCP or router connected to that 10.3.0.0/24 network)

 

 

root@zdcpe1cpe01brgemu01-201908271954:~# vppctl show dhcp client

[0] GigabitEthernet0/4/0 state DHCP_DISCOVER no address

 

root@zdcpe1cpe01brgemu01-201908271954:~# vppctl show snat detail

SNAT mode: dynamic translations enabled

tap-1 in

GigabitEthernet0/4/0 out

SNAT pool addresses interfaces:

GigabitEthernet0/4/0

0 users, 0 outside addresses, 0 active sessions, 0 static mappings

Hash table in2out

    0 active elements

    0 free lists

    0 linear search buckets

Hash table out2in

    0 active elements

    0 free lists

    0 linear search buckets

Hash table worker-by-in

    0 active elements

    0 free lists

    0 linear search buckets

Hash table worker-by-out

    0 active elements

    0 free lists

    0 linear search buckets

 

 

Thanks for your help,

Michal

 

From: onap-discuss@... <onap-discuss@...> On Behalf Of Multanen, Eric W
Sent: Tuesday, August 27, 2019 5:39 PM
To: Ptacek Michal <Michal.Ptacek@...>; onap-discuss@...; FREEMAN, BRIAN D <bf1936@...>; m.ptacek@...; stephen.gooch@...; Bin.Yang@...; Eddy.Raineri@...
Cc: morgan.richomme@...; PLATANIA, MARCO <platania@...>; 'Bartlomiej Grzybowski' <b.grzybowski@...>
Subject: Re: [onap-discuss] vCPE usecase: DHCP issue

 

Re. versioning – I’m not aware of any recent changes to the heat or scripts (not that I’m keeping a close eye).

 

Can you find a way to capture packets on the network between vBNG and vBRG?  (I suppose this would only demonstrate that the response got out of the vBNG)

 

On the vBRG, see what following returns:

vppctl show dhcp client

vppctl show snat detail

 

From: Ptacek Michal <Michal.Ptacek@...>
Sent: Tuesday, August 27, 2019 10:20 AM
To: onap-discuss@...; Multanen, Eric W <eric.w.multanen@...>; FREEMAN, BRIAN D <bf1936@...>; m.ptacek@...; stephen.gooch@...; Bin.Yang@...; Eddy.Raineri@...
Cc: morgan.richomme@...; PLATANIA, MARCO <platania@...>; 'Bartlomiej Grzybowski' <b.grzybowski@...>
Subject: RE: [onap-discuss] vCPE usecase: DHCP issue

 

Yes Eric, all pcap’s are from BNG. Maybe there was some attempt to deliver DHCP response from BNG to BRG but definitely nothing came to BRG side.

 

Any thoughts about that versioning problem ?

 

robot/testsuite 1.4.2 (dublin version)

vcpe scripts  master (el-alto)

vcpe images master / 1.5.0-SNAPSHOT demo scripts (el-alto)

 

thanks,

Michal

 

 

 

 

From: onap-discuss@... <onap-discuss@...> On Behalf Of Multanen, Eric W
Sent: Tuesday, August 27, 2019 4:07 PM
To: onap-discuss@...; Ptacek Michal <Michal.Ptacek@...>; FREEMAN, BRIAN D <bf1936@...>; m.ptacek@...; stephen.gooch@...; Bin.Yang@...; Eddy.Raineri@...
Cc: morgan.richomme@...; PLATANIA, MARCO <platania@...>; 'Bartlomiej Grzybowski' <b.grzybowski@...>
Subject: Re: [onap-discuss] vCPE usecase: DHCP issue

 

ok – took a look at these pcap file.

 

if I’m not mistaken, (these were captures on vBNG right) – it looks to me like the vBNG is sending the dhcp reply to the vBRG out the interface with IP 10.3.0.1.

 

So, if that’s right, then I conclude that the vBRG is not receiving the reply.

 

 

-2:-56:-34.935995 IP (tos 0x10, ttl 128, id 0, offset 0, flags [DF], proto UDP (17), length 318)

    10.3.0.1.bootps > 255.255.255.255.bootpc: BOOTP/DHCP, Reply, length 290, xid 0x5c3f82c, Flags [none]

          Your-IP 10.3.0.8

          Server-IP 10.3.0.1

          Gateway-IP 10.4.0.3

          Client-Ethernet-Address fa:16:3e:50:74:1c

          Vendor-rfc1048 Extensions

            Magic Cookie 0x63825363

            Subnet-Mask Option 1, length 4: 255.255.255.0

            Default-Gateway Option 3, length 4: 10.3.0.1

            Lease-Time Option 51, length 4: 300

            DHCP-Message Option 53, length 1: Offer

            Server-ID Option 54, length 4: 10.4.0.1

            Agent-Information Option 82, length 20:

              Circuit-ID SubOption 1, length 4: ^@^@^@^A

              Remote-ID SubOption 2, length 6: M-z^V>Pt^\

              Unknown SubOption 5, length 4:

                0x0000:  0a03 0001

 

From: onap-discuss@... <onap-discuss@...> On Behalf Of Michal Ptacek
Sent: Monday, August 26, 2019 2:29 PM
To: onap-discuss@...; Multanen, Eric W <eric.w.multanen@...>; FREEMAN, BRIAN D <bf1936@...>; m.ptacek@...; stephen.gooch@...; Bin.Yang@...; Eddy.Raineri@...
Cc: morgan.richomme@...; PLATANIA, MARCO <platania@...>; 'Bartlomiej Grzybowski' <b.grzybowski@...>
Subject: Re: [onap-discuss] vCPE usecase: DHCP issue

 

Thanks for valuable hints:

 

Ad1)

 

root@zdcpe1cpe01bng01-201908251807:~# vppctl show vbng aaa

Enabled NAS Port Config File

  False    5060   /etc/vpp/vbng-aaa.cfg

 

root@zdcpe1cpe01bng01-201908251807:~# vppctl show vbng dhcp4

    RX FIB       Src Address  Servers FIB,Address

       0          10.4.0.3    0,10.4.0.1

 

Ad2) try to restart „vpp“ …. I never observed any improvement on BRGemu from this action, usually both tap interfaces were not initialized properly and I need to redeploy vCPE to get them working again

 

Ad3) pcap traces (pls see attached)

vpe_int_only.pcap  …..  „vppctl pcap tx trace on intfc GigabitEthernet0/4/0“

vpe.pcap                  …..   „vppctl pcap tx trace on“

 

to me it looks that BRG received response from DHCP (vpe.pcap) but as it’s not visible in „vpe_int_only.pcap“ it was never transmitted back to BRGemu

 

how can we fix that ? 😊

 

M.

 

From: onap-discuss@... <onap-discuss@...> On Behalf Of Multanen, Eric W
Sent: Monday, August 26, 2019 8:04 PM
To: FREEMAN, BRIAN D <bf1936@...>; onap-discuss@...; Ptacek Michal <Michal.Ptacek@...>; m.ptacek@...; stephen.gooch@...; Bin.Yang@...; Eddy.Raineri@...
Cc: morgan.richomme@...; PLATANIA, MARCO <platania@...>; 'Bartlomiej Grzybowski' <b.grzybowski@...>
Subject: Re: [onap-discuss] vCPE usecase: DHCP issue

 

As already stated in the thread  – the dhcp response gets back to the vbng – but either vbng is not sending or vbrg not receiving (which we already know since trace on vbrg does not show any inputs)

 

you could try the ‘vppctl pcap tx ..’ commands on the vbng interface connected to the vbng -  GigabitEthernet0/4/0

That should verify if anything is being transmitted from that port.

 

Also, see (on the vbng) what the following return:

vppctl show vbng aaa

vppctl show vbng dhcp4

 

e.g. something like:

$ vppctl show vbng dhcp4

    RX FIB       Src Address  Servers FIB,Address

       0          10.4.0.3    0,10.4.0.1

 

$ vppctl show vbng aaa

Enabled NAS Port Config File

  False    5060   /etc/vpp/vbng-aaa.cfg

 

Eric

 

From: FREEMAN, BRIAN D <bf1936@...>
Sent: Monday, August 26, 2019 1:36 PM
To: onap-discuss@...; michal.ptacek@...; m.ptacek@...; Multanen, Eric W <eric.w.multanen@...>; stephen.gooch@...; Bin.Yang@...; Eddy.Raineri@...
Cc: morgan.richomme@...; PLATANIA, MARCO <platania@...>; 'Bartlomiej Grzybowski' <b.grzybowski@...>
Subject: RE: [onap-discuss] vCPE usecase: DHCP issue

 

“systemctl restart vpp” on the BRGEMU isnt working for you ?

Might need to do the same on the vBNG – for some reason I remember having to poke the tap’s sometimes but that was more when talking to the vGW not the vBRT to vBNG.

 

Rx frames on the BRGEMU are too low looks like vpp isnt recieving or at least not detecting the responses from the vBNG (stating the obvious)

 

    tx frames ok                                         101

    tx bytes ok                                        32926

    rx frames ok                                           4

    rx bytes ok                                          224

 

 

Brian

 

 

vBRG not responding to configuration from SDNC

Symptom: Run healthcheck.py and the test fails to connect to connect to vBRG. (Note you need to edit the healthcheck.py to use the correct IP address for vBRG. The default is 10.3.0.2).

This is caused by vpp not working properly inside vBRG. There is no deterministic fix for this problem until we have a stable vBRG image. Temporarily, you may try to either restart the vBRG VM or ssh to vBRG and 'systemctl restart vpp' and then retry healthcheck.py. Note that 'systemctl restart vpp' may work better that rebooting the VM but there is no guarantee.

Inside vBRG you can also check the status with 'vppctl show int'. If vpp works properly, you should be able to see that both tap-0 and tap-1 in 'up' state. An example is below.

 

 

From: onap-discuss@... <onap-discuss@...> On Behalf Of Michal Ptacek
Sent: Monday, August 26, 2019 1:27 PM
To: onap-discuss@...; FREEMAN, BRIAN D <bf1936@...>; m.ptacek@...; 'Multanen, Eric W' <eric.w.multanen@...>; stephen.gooch@...; Bin.Yang@...; Eddy.Raineri@...
Cc: morgan.richomme@...; PLATANIA, MARCO <platania@...>; 'Bartlomiej Grzybowski' <b.grzybowski@...>
Subject: Re: [onap-discuss] vCPE usecase: DHCP issue

 

That’s right Brian

 

from the „vppctl show ip fib“ difference on my BNG node and the one in integration lab, I see two rules missing.

Not sure if they are supposed to be added automagically after connections are established ….

 

MY ENV                                                                                                                                                                                            WINDRIVER/INTEL LAB

 

Michal

g

From: onap-discuss@... <onap-discuss@...> On Behalf Of Brian Freeman
Sent: Monday, August 26, 2019 7:18 PM
To: m.ptacek@...; 'Multanen, Eric W' <eric.w.multanen@...>; onap-discuss@...; stephen.gooch@...; Bin.Yang@...; Eddy.Raineri@...
Cc: morgan.richomme@...; PLATANIA, MARCO <platania@...>; 'Bartlomiej Grzybowski' <b.grzybowski@...>
Subject: Re: [onap-discuss] vCPE usecase: DHCP issue

 

I think we already confirm that kea is sending the DHCP OFFER to the vBNG right ? its jsut not making it from the vBNG to the vBRGEMU

 

 

 

Brian

 

 

From: m.ptacek@... <m.ptacek@...>
Sent: Monday, August 26, 2019 1:12 PM
To: 'Multanen, Eric W' <eric.w.multanen@...>; FREEMAN, BRIAN D <bf1936@...>; onap-discuss@...; stephen.gooch@...; Bin.Yang@...; Eddy.Raineri@...
Cc: morgan.richomme@...; PLATANIA, MARCO <platania@...>; 'Bartlomiej Grzybowski' <b.grzybowski@...>
Subject: RE: [onap-discuss] vCPE usecase: DHCP issue

 

Tap interfaces looks to be up, 10.3.0.1 on BNG looks correct … just 10.3.0.2 on BRG is missing

 

please see attached info collected from BRG and BNG,

Maybe you will see something I don’t see …

 

Thanks a lot for your support,

Michal

 

From: Multanen, Eric W <eric.w.multanen@...>
Sent: Monday, August 26, 2019 6:41 PM
To: FREEMAN, BRIAN D <bf1936@...>; onap-discuss@...; m.ptacek@...; stephen.gooch@...; Bin.Yang@...; Eddy.Raineri@...
Cc: morgan.richomme@...; PLATANIA, MARCO <platania@...>; 'Bartlomiej Grzybowski' <b.grzybowski@...>
Subject: RE: [onap-discuss] vCPE usecase: DHCP issue

 

you can check in the vBNG:  vppctl show ip fib

to verify that routing info is correct.

 

From: FREEMAN, BRIAN D <bf1936@...>
Sent: Monday, August 26, 2019 11:33 AM
To: onap-discuss@...; m.ptacek@...; stephen.gooch@...; Bin.Yang@...; Eddy.Raineri@...
Cc: morgan.richomme@...; PLATANIA, MARCO <platania@...>; Multanen, Eric W <eric.w.multanen@...>; 'Bartlomiej Grzybowski' <b.grzybowski@...>
Subject: RE: [onap-discuss] vCPE usecase: DHCP issue

 

Its the tunnel-tap between the BRG and the BNG.

There is also a routing function in the BNG that needs to be up.

So I would be looking inside vppctl

 

vpp# show interface

              Name               Idx       State          Counter          Count    

GigabitEthernet0/4/0              1         up       rx packets                 14078

                                                     rx bytes                 1864486

                                                     tx packets                  2605

                                                     tx bytes                  830306

                                                     drops                      11477

                                                     ip4                         2602

                                                     ip6                        11471

GigabitEthernet0/6/0              2         up       rx packets                 13201

                                                     rx bytes                 1741980

                                                     tx packets                  2594

                                                     tx bytes                  876510

                                                     drops                      10608

                                                     ip4                         2593

                                                     ip6                        10606

GigabitEthernet0/7/0              3         up       rx packets                 11477

                                                     rx bytes                  986884

                                                     tx packets                     1

                                                     tx bytes                      60

                                                     drops                      11476

                                                     ip6                        11472

local0                            0        down     

tap-0                             4         up       rx packets                    22

                                                     rx bytes                    1908

                                                     tx packets                    10

                                                     tx bytes                     796

                                                     drops                         20

                                                     ip4                           12

                                                     ip6                            8

 

 

vpp# show interface address

GigabitEthernet0/4/0 (up):

  10.3.0.1/24

GigabitEthernet0/6/0 (up):

  10.4.0.3/24

GigabitEthernet0/7/0 (up):

  10.1.0.10/24

local0 (dn):

tap-0 (up):

  192.168.40.41/24

 

 

brg emu

 

vpp# show interface

              Name               Idx       State          Counter          Count    

GigabitEthernet0/4/0              1         up       rx packets                 14359

                                                     rx bytes                 1841816

                                                     tx packets                  2605

                                                     tx bytes                  878406

                                                     drops                      11764

                                                     ip4                         2595

                                                     ip6                        11752

local0                            0        down     

tap-0                             2         up       rx packets                     5

                                                     rx bytes                     390

                                                    drops                          8

tap-1                             3         up       rx packets                     9

                                                     rx bytes                     754

                                                     drops                          8

                                                     ip4                            7

                                                     ip6                            2

 

 

 

 

vpp# show interface address

GigabitEthernet0/4/0 (up):

  10.3.0.2/24

local0 (dn):

tap-0 (up):

  l2 bridge bd_id 10 shg 0

tap-1 (up):

  20.0.0.40/24

 

 

From: onap-discuss@... <onap-discuss@...> On Behalf Of Michal Ptacek via Lists.Onap.Org
Sent: Monday, August 26, 2019 10:43 AM
To: FREEMAN, BRIAN D <bf1936@...>; stephen.gooch@...; Bin.Yang@...; Eddy.Raineri@...; onap-discuss@...
Cc: morgan.richomme@...; PLATANIA, MARCO <platania@...>; 'Multanen, Eric W' <eric.w.multanen@...>; 'Bartlomiej Grzybowski' <b.grzybowski@...>
Subject: [onap-discuss] vCPE usecase: DHCP issue

 

Hi,

 

In VCPE usecase, did anyone encounter DHCP issue for BRG interface ??

 

Long story short:

BRGEMU (DHCP client) send DHCP request, forwarded by BNG (relay server) towards DHCP server

DHCP server returns DHCP offer (port 67 -> port 67) to BNG …. but then it’s somehow dropped and not forwarded back to BRGEMU !!

 

 

More detailed story:

It looks that main problem is that BRG doesn’t receive it’s IP (10.3.0.2) from DHCP !!!

 

root@zdcpe1cpe01brgemu01-201908251807:~# vppctl show int address

GigabitEthernet0/4/0 (up):

local0 (dn):

tap-0 (up):

  l2 bridge bd_id 10 shg 0

tap-1 (up):

  20.0.0.40/24

 

root@zdcpe1cpe01brgemu01-201908251807:~# vppctl show hardware

              Name                Idx   Link  Hardware

GigabitEthernet0/4/0               1     up   GigabitEthernet0/4/0

  Ethernet address fa:16:3e:50:74:1c

  Red Hat Virtio

    carrier up full duplex speed 10000 mtu 9216

    rx queues 1, rx desc 256, tx queues 1, tx desc 256

 

    tx frames ok                                         101

    tx bytes ok                                        32926

    rx frames ok                                           4

    rx bytes ok                                          224

 

 

If I understand it correctly, BRG should get IP address via DHCP – Option 82 (means BNG is relay host between BNG and DHCP server)

I also see some traffic on DHCP server for that MAC address, however don’t know where replies got dropped

 

 

root@zdcpe1cpe01dhcp01-201908251807:~# tcpdump -i any port 67

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode

listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes

18:27:55.636784 IP 10.4.0.3.bootpc > 10.4.0.1.bootps: BOOTP/DHCP, Request from fa:16:3e:50:74:1c (oui Unknown), length 307

18:27:55.639311 IP 10.4.0.1.bootps > 10.4.0.3.bootps: BOOTP/DHCP, Reply, length 290

18:28:00.641081 IP 10.4.0.3.bootpc > 10.4.0.1.bootps: BOOTP/DHCP, Request from fa:16:3e:50:74:1c (oui Unknown), length 307

18:28:00.642956 IP 10.4.0.1.bootps > 10.4.0.3.bootps: BOOTP/DHCP, Reply, length 290

18:28:05.638780 IP 10.4.0.3.bootpc > 10.4.0.1.bootps: BOOTP/DHCP, Request from fa:16:3e:50:74:1c (oui Unknown), length 307

18:28:05.641179 IP 10.4.0.1.bootps > 10.4.0.3.bootps: BOOTP/DHCP, Reply, length 290

 

 

On BNG it looks that traffic is flowing …

 

root@zdcpe1cpe01bng01-201908251807:~# vppctl show  node count

   Count                    Node                  Reason

       185           vbng-dhcp-to-server          DHCP packets relayed to the server

       183           vbng-dhcp-to-server          DHCP packets relayed to clients

         1           vbng-dhcp-to-server          DHCP packets failed to pass the AAA check.

         1             ip4-udp-lookup             no error

         8                ip6-input               ip6 adjacency drop

         5                ip4-glean               ARP requests sent

        2             ip4-icmp-input             echo replies sent

         2                arp-input               ARP replies sent

         2                arp-input               ARP replies received

 

root@zdcpe1cpe01bng01-201908251807:~# vppctl show trace

------------------- Start of thread 0 vpp_main -------------------

Packet 1

 

00:18:02:693363: dpdk-input

  GigabitEthernet0/4/0 rx queue 0

  buffer 0x3618: current data 14, length 312, free-list 0, clone-count 0, totlen-nifb 0, trace 0x0

  PKT MBUF: port 0, nb_segs 1, pkt_len 326

    buf_len 2176, data_len 326, ol_flags 0x0, data_off 128, phys_addr 0x6a4d4500

    packet_type 0x0

  IP4: fa:16:3e:50:74:1c -> ff:ff:ff:ff:ff:ff

  UDP: 0.0.0.0 -> 255.255.255.255

    tos 0x00, ttl 128, length 312, checksum 0x39b6

    fragment id 0x0000

  UDP: 68 -> 67

    length 292, checksum 0x0000

00:18:02:693414: ip4-input

  UDP: 0.0.0.0 -> 255.255.255.255

    tos 0x00, ttl 128, length 312, checksum 0x39b6

    fragment id 0x0000

  UDP: 68 -> 67

    length 292, checksum 0x0000

00:18:02:693428: ip4-lookup

  fib 0 dpo-idx 8 flow hash: 0x00000000

  UDP: 0.0.0.0 -> 255.255.255.255

    tos 0x00, ttl 128, length 312, checksum 0x39b6

    fragment id 0x0000

  UDP: 68 -> 67

    length 292, checksum 0x0000

00:18:02:693434: ip4-local

    UDP: 0.0.0.0 -> 255.255.255.255

      tos 0x00, ttl 128, length 312, checksum 0x39b6

      fragment id 0x0000

    UDP: 68 -> 67

      length 292, checksum 0x0000

00:18:02:693436: ip4-udp-lookup

  UDP: src-port 68 dst-port 67

00:18:02:693439: vbng-dhcp-to-server

  DHCP proxy: sent to server 10.4.0.1

  original_sw_if_index: 1, sw_if_index: 1

 

00:18:02:693444: ip4-lookup

  fib 0 dpo-idx 7 flow hash: 0x00000000

  UDP: 10.4.0.3 -> 10.4.0.1

    tos 0x00, ttl 128, length 335, checksum 0x2593

    fragment id 0x0000

  UDP: 68 -> 67

    length 315, checksum 0x0000

00:18:02:693451: ip4-rewrite

  tx_sw_if_index 2 dpo-idx 7 : ipv4 via 10.4.0.1 GigabitEthernet0/6/0: fa163ecd2d63fa163e957b450800 flow hash: 0x00000000

  00000000: fa163ecd2d63fa163e957b4508004500014f000000007f1126930a0400030a04

  00000020: 000100440043013b00000101060005c3f82c00008000000000000000

00:18:02:693453: GigabitEthernet0/6/0-output

  GigabitEthernet0/6/0

  IP4: fa:16:3e:95:7b:45 -> fa:16:3e:cd:2d:63

  UDP: 10.4.0.3 -> 10.4.0.1

    tos 0x00, ttl 127, length 335, checksum 0x2693

    fragment id 0x0000

  UDP: 68 -> 67

    length 315, checksum 0x0000

00:18:02:693455: GigabitEthernet0/6/0-tx

  GigabitEthernet0/6/0 tx queue 0

  buffer 0x3618: current data 0, length 349, free-list 0, clone-count 0, totlen-nifb 0, trace 0x0

  IP4: fa:16:3e:95:7b:45 -> fa:16:3e:cd:2d:63

  UDP: 10.4.0.3 -> 10.4.0.1

    tos 0x00, ttl 127, length 335, checksum 0x2693

    fragment id 0x0000

  UDP: 68 -> 67

    length 315, checksum 0x0000

 

Packet 2

 

00:18:02:696453: dpdk-input

  GigabitEthernet0/6/0 rx queue 0

  buffer 0xf3f: current data 14, length 318, free-list 0, clone-count 0, totlen-nifb 0, trace 0x1

  PKT MBUF: port 1, nb_segs 1, pkt_len 332

    buf_len 2176, data_len 332, ol_flags 0x0, data_off 128, phys_addr 0x6a438ec0

    packet_type 0x0

  IP4: fa:16:3e:cd:2d:63 -> fa:16:3e:95:7b:45

  UDP: 10.4.0.1 -> 10.4.0.3

    tos 0x10, ttl 128, length 318, checksum 0xe593

    fragment id 0x0000, flags DONT_FRAGMENT

  UDP: 67 -> 67

    length 298, checksum 0x3375

00:18:02:696473: ip4-input

  UDP: 10.4.0.1 -> 10.4.0.3

    tos 0x10, ttl 128, length 318, checksum 0xe593

    fragment id 0x0000, flags DONT_FRAGMENT

  UDP: 67 -> 67

    length 298, checksum 0x3375

00:18:02:696486: ip4-lookup

  fib 0 dpo-idx 6 flow hash: 0x00000000

  UDP: 10.4.0.1 -> 10.4.0.3

    tos 0x10, ttl 128, length 318, checksum 0xe593

    fragment id 0x0000, flags DONT_FRAGMENT

  UDP: 67 -> 67

    length 298, checksum 0x3375

00:18:02:696487: ip4-local

    UDP: 10.4.0.1 -> 10.4.0.3

      tos 0x10, ttl 128, length 318, checksum 0xe593

      fragment id 0x0000, flags DONT_FRAGMENT

    UDP: 67 -> 67

      length 298, checksum 0x3375

00:18:02:696488: ip4-udp-lookup

  UDP: src-port 67 dst-port 67

00:18:02:696489: vbng-dhcp-to-client

  DHCP proxy: broadcast to client from 10.3.0.1

  original_sw_if_index: 1, sw_if_index: 1

 

BUT on BRG it’s somehow dead

 

root@zdcpe1cpe01brgemu01-201908251807:~# vppctl show node count

   Count                    Node                  Reason

         7                tapcli-rx               no error

         2                ip6-input               ip6 adjacency drop

         7                l2-learn                L2 learn packets

         1                l2-learn                L2 learn misses

         6                l2-learn                L2 learn hits

         7                l2-input                L2 input packets

         7                l2-flood                L2 flood packets

         7                l2-flood                L2 replication complete

         4                arp-input               IP4 destination address not local to subnet

 

root@zdcpe1cpe01brgemu01-201908251807:~# vppctl trace add dpdk-input 10

 

root@zdcpe1cpe01brgemu01-201908251807:~# vppctl show trace

------------------- Start of thread 0 vpp_main -------------------

No packets in trace buffer

 

(restart of BRG will not allow interfaces to setup properly, so fastest way for restore it is to run ./vcpe.py infra)

 

Any hint very appreciated …

 

Thank you,

Michal

 

PS: I am now using same VCPE images on integration lab (just for case 😊)

 

 

 

 

 

  

Re: [AAI] [portal] Not able to access AAI GUI from ONAP Portal

Aniello Paolo Malinconico
 

[OSAM] How to install OSAM Core and Gateway in ONAP?

LTE Next Generation
 

Dear All,

 

I would like to integrate SEBA Pod with ONAP.

May I know if there is any documentation for installation of OSAM along with ONAP?

 

Kind Regards,

Hanif

[AAI] [portal] Not able to access AAI GUI from ONAP Portal

Thamlur Raju
 

Hi Team,

 

we are using Dublin release of AAI, we are not able to access the AAI UI.

 

AAI pods are running fine…

 

#kubectl get pods | grep aai

 

dev-aai-aai-6685b89bcc-slwck                                 1/1     Running      0          35d

dev-aai-aai-babel-5d75865f7b-r25sm                           2/2     Running      0          35d

dev-aai-aai-champ-758d98b796-sswbs                           2/2     Running      0          35d

dev-aai-aai-data-router-6fb968c754-24kcx                     2/2     Running      0          35d

dev-aai-aai-elasticsearch-57d469cdc5-cfjmd                   1/1     Running      0          35d

dev-aai-aai-gizmo-694775589-4r7h7                            2/2     Running      0          35d

dev-aai-aai-graphadmin-76b5d8bcd9-vpq6d                      2/2     Running      0          35d

dev-aai-aai-graphadmin-create-db-schema-gdjhq                0/1     Completed    0          35d

dev-aai-aai-modelloader-559f886bb5-h8gvz                     2/2     Running      0          35d

dev-aai-aai-resources-c9d8cbccc-lgskx                        2/2     Running      0          35d

dev-aai-aai-schema-service-674b5688b6-4dpzz                  2/2     Running      0          35d

dev-aai-aai-search-data-6dd75ddc5-2fxwv                      2/2     Running      0          35d

dev-aai-aai-sparky-be-b758d9d58-qznjl                        2/2     Running      0          35d

dev-aai-aai-spike-7475bd56d-ghbvd                            2/2     Running      0          35d

dev-aai-aai-traversal-5dbc94c748-8gb58                       2/2     Running      0          35d

dev-aai-aai-traversal-update-query-data-6b2hg                0/1     Completed    0          35d

dev-pomba-pomba-aaictxbuilder-7b6d4f7b57-wchhw               2/2     Running      0          35d

 

 

I get this error in browser web console:

 

XML Parsing Error: no root element found

Location: https://portal.api.simpledemo.onap.org:30225/ONAPPORTAL/portalApi/auditLog/store?affectedAppId=7&type=app&comment=https://aai.ui.simpledemo.onap.org:30220/services/aai/webapp/index.html#/viewInspect

Line Number 1, Column 1:

 

In the browser Network tab (as shown in below), it is giving 302 status… and I tried to open it in new tab as https://aai.ui.simpledemo.onap.org:30220/services/aai/webapp/index.html#/viewInspect

But it is redirecting to the PORTAL site as,  https://portal.api.simpledemo.onap.org:30225/ONAPPORTAL/login.htm#/viewInspectLine

 

 

 

I tried in different browsers but same error…

 

Please suggest something on this issue.

 

 

Thanks & Regards,

Thamlur Raju

NS-NDU-OSS

Bengaluru | India

| Ext : 858518

 

 

============================================================================================================================ Disclaimer: This message and the information contained herein is proprietary and confidential and subject to the Tech Mahindra policy statement, you may review the policy at http://www.techmahindra.com/Disclaimer.html externally http://tim.techmahindra.com/tim/disclaimer.html internally within TechMahindra. ============================================================================================================================

Re: ONAP deployment on AWS #casablanca

Marco Platania
 

AAI manages OOM charts internally, so you need to clone the OOM repo in the following way, so as to fetch also the submodules:

 

git clone --recurse-submodules -b 4.0.0-ONAP https://gerrit.onap.org/r/oom

 

I’m not familiar with deployment in AWS, so I can’t add more on that.

 

Marco

 

 

From: Pritesh Gupta <gupta.pritesh@...>
Date: Friday, August 30, 2019 at 2:55 AM
To: "PLATANIA, MARCO (MARCO)" <platania@...>, "onap-discuss@..." <onap-discuss@...>
Subject: Re: [onap-discuss] ONAP deployment on AWS #casablanca

 

Hi Marco,

Thanks for reply. Yes i will be using DevStack to deploy VNF. Just wanted some help to understand if its right way to deploy Onap Casablanca using OOM on AWS or there is also alternate way to do so. AWS EFS is facing some issue while deploying later modules of ONAP.

Also wanted to check which version is stable to perform basic vFW demo of ONAP. I tried to deploy Dublin but OOM doesnt have AAI charts in it. Hence need some help with links or documents that will guide to deploy required modules for vFW demo.

Dublin AAI Molde Loader fails to ingest SDC service models

Vivekanandan Muthukrishnan
 

HI AAI Team,

We are seeing SDC service distribution error, and for some reason AAI model loader is not able to ingest the SDC service models.

In the AAI Resources logs, we see that ModelLoader:Extension class not found: org.onap.aai.extensions.v16.serviceDesignAndCreation.ModelExtension message. 

Did anyone face this issue? Are there any workaround to resolve this one. Please refer the below log snippet for more information.

AAI Model Loader Log snippet

2019-08-30T10:49:41.002Z|98fe1d6d-35e3-456a-8106-f5c7bda90cf7|pool-2-thread-1|ModelLoader|Event-Bus|org.onap.aai.modelloader.entity.model.ModelArtifactParser||INFO|MDLSVC0003I|MDLSVC0003I Distribution event: Model parsed =====>>>> Model-invariant-Id: 520909f6-fa56-4bd7-a70d-88a8c1bf3db6 Model-Version-Id: 19f8a1f4-701d-42db-abfe-4152bf385000|
2019-08-30T10:49:41.011Z|98fe1d6d-35e3-456a-8106-f5c7bda90cf7|pool-2-thread-1|ModelLoader|Event-Bus|org.onap.aai.modelloader.entity.model.ModelArtifactParser||INFO|MDLSVC0003I|MDLSVC0003I Distribution event: Model parsed =====>>>> Model-invariant-Id: a96a90f0-e4bf-4b07-af17-689cece2d7a3 Model-Version-Id: 34e46a2b-d3c3-41b1-9c05-3231e2880e51|
2019-08-30T10:49:41.020Z|98fe1d6d-35e3-456a-8106-f5c7bda90cf7|pool-2-thread-1|ModelLoader|Event-Bus|org.onap.aai.modelloader.entity.model.ModelArtifactParser||INFO|MDLSVC0003I|MDLSVC0003I Distribution event: Model parsed =====>>>> Model-invariant-Id: 7dfe59ac-0045-4c93-b258-ca8753ad5537 Model-Version-Id: 94032bd5-00cf-49ac-a9d4-fae54d675209|
2019-08-30T10:49:41.024Z|98fe1d6d-35e3-456a-8106-f5c7bda90cf7|pool-2-thread-1|ModelLoader|Event-Bus|org.onap.aai.modelloader.entity.model.ModelArtifactParser||INFO|MDLSVC0003I|MDLSVC0003I Distribution event: Model parsed =====>>>> Model-invariant-Id: 3417dc7b-a997-4bf1-892a-fbbfabaaad32 Model-Version-Id: 89d6e442-1953-49b5-8e9b-4d521c2fad8e|
2019-08-30T10:49:41.024Z|98fe1d6d-35e3-456a-8106-f5c7bda90cf7|pool-2-thread-1|ModelLoader|Event-Bus|org.onap.aai.modelloader.extraction.VnfCatalogExtractor||INFO|MDLSVC0003I|MDLSVC0003I Distribution event: Extracting CSAR archive: service-VlbService01-csar.csar|
2019-08-30T10:49:41.051Z|98fe1d6d-35e3-456a-8106-f5c7bda90cf7|pool-2-thread-1|ModelLoader|Event-Bus|AAIRESTClient||INFO|AC0001I|AC0001I GET request at url = https://aai.onap:8443/aai/v16/service-design-and-creation/models/model/a96a90f0-e4bf-4b07-af17-689cece2d7a3|
2019-08-30T10:49:41.332Z|98fe1d6d-35e3-456a-8106-f5c7bda90cf7|pool-2-thread-1|ModelLoader|Event-Bus|AAIRESTClient||INFO|AC0003I|AC0003I GET request operation time = 280 ms for link = https://aai.onap:8443/aai/v16/service-design-and-creation/models/model/a96a90f0-e4bf-4b07-af17-689cece2d7a3|
2019-08-30T10:49:41.332Z|98fe1d6d-35e3-456a-8106-f5c7bda90cf7|pool-2-thread-1|ModelLoader|Event-Bus|AAIRESTClient||INFO|AC0004I|AC0004I request at url = https://aai.onap:8443/aai/v16/service-design-and-creation/models/model/a96a90f0-e4bf-4b07-af17-689cece2d7a3 resulted in http response: 404 Not Found|
2019-08-30T10:49:41.332Z|98fe1d6d-35e3-456a-8106-f5c7bda90cf7|pool-2-thread-1|ModelLoader|Event-Bus|org.onap.aai.modelloader.restclient.AaiRestClient||INFO|MDLSVC0010I|MDLSVC0010I A&AI request payload: <model xmlns="http://org.onap.aai.inventory/v16">
    <model-invariant-id>a96a90f0-e4bf-4b07-af17-689cece2d7a3</model-invariant-id>
    <model-type>resource</model-type>
    <model-vers>
        <model-ver>
            <model-version-id>34e46a2b-d3c3-41b1-9c05-3231e2880e51</model-version-id>
            <model-name>VlbDnsVnf..dnsscaling..module-1</model-name>
            <model-version>1</model-version>
            <model-elements>
                <model-element>
                    <new-data-del-flag>T</new-data-del-flag>
                    <cardinality>unbounded</cardinality>
                    <model-elements>
                        <model-element>
                            <new-data-del-flag>T</new-data-del-flag>
                            <cardinality>unbounded</cardinality>
                            <model-elements>
                                <model-element>
                                    <new-data-del-flag>F</new-data-del-flag>
                                    <cardinality>unbounded</cardinality>
                                    <model-elements/>
                                    <relationship-list>
                                        <relationship>
                                            <related-to>model-ver</related-to>
                                            <relationship-data>
                                                <relationship-key>model-ver.model-version-id</relationship-key>
                                                <relationship-value>f6a038c2-820c-42ba-8c2b-375e24e8f932</relationship-value>
                                            </relationship-data>
                                            <relationship-data>
                                                <relationship-key>model.model-invariant-id</relationship-key>
                                                <relationship-value>3f4c7204-739b-4bbb-87a7-8a6856439c90</relationship-value>
                                            </relationship-data>
                                        </relationship>
                                    </relationship-list>
                                </model-element>
                                <model-element>
                                    <new-data-del-flag>F</new-data-del-flag>
                                    <cardinality>unbounded</cardinality>
                                    <model-elements/>
                                    <relationship-list>
                                        <relationship>
                                            <related-to>model-ver</related-to>
                                            <relationship-data>
                                                <relationship-key>model-ver.model-version-id</relationship-key>
                                                <relationship-value>abcc54bc-bb74-49dc-9043-7f7171707545</relationship-value>
                                            </relationship-data>
                                            <relationship-data>
                                                <relationship-key>model.model-invariant-id</relationship-key>
                                                <relationship-value>97c26c99-6870-44c1-8a07-1d900d3f4ce6</relationship-value>
                                            </relationship-data>
                                        </relationship>
                                    </relationship-list>
                                </model-element>
                                <model-element>
                                    <new-data-del-flag>F</new-data-del-flag>
                                    <cardinality>unbounded</cardinality>
                                    <model-elements/>
                                    <relationship-list>
                                        <relationship>
                                            <related-to>model-ver</related-to>
                                            <relationship-data>
                                                <relationship-key>model-ver.model-version-id</relationship-key>
                                                <relationship-value>36200fb5-f251-4f5d-a520-7c5ad5c2cd4b</relationship-value>
                                            </relationship-data>
                                            <relationship-data>
                                                <relationship-key>model.model-invariant-id</relationship-key>
                                                <relationship-value>bace8d1c-a261-4041-9e37-823117415d0f</relationship-value>
                                            </relationship-data>
                                        </relationship>
                                    </relationship-list>
                                </model-element>
                                <model-element>
                                    <new-data-del-flag>T</new-data-del-flag>
                                    <cardinality>unbounded</cardinality>
                                    <model-elements/>
                                    <relationship-list>
                                        <relationship>
                                            <related-to>model-ver</related-to>
                                            <relationship-data>
                                                <relationship-key>model-ver.model-version-id</relationship-key>
                                                <relationship-value>5761e0a7-c6df-4d8a-9ebd-b8f445054dec</relationship-value>
                                            </relationship-data>
                                            <relationship-data>
                                                <relationship-key>model.model-invariant-id</relationship-key>
                                                <relationship-value>96129eb9-f0de-4e05-8af2-73146473f766</relationship-value>
                                            </relationship-data>
                                        </relationship>
                                    </relationship-list>
                                </model-element>
                            </model-elements>
                            <relationship-list>
                                <relationship>
                                    <related-to>model-ver</related-to>
                                    <relationship-data>
                                        <relationship-key>model-ver.model-version-id</relationship-key>
                                        <relationship-value>8ecb2c5d-7176-4317-a255-26274edfdd53</relationship-value>
                                    </relationship-data>
                                    <relationship-data>
                                        <relationship-key>model.model-invariant-id</relationship-key>
                                        <relationship-value>ff69d4e0-a8e8-4108-bdb0-dd63217e63c7</relationship-value>
                                    </relationship-data>
                                </relationship>
                            </relationship-list>
                        </model-element>
                    </model-elements>
                    <relationship-list>
                        <relationship>
                            <related-to>model-ver</related-to>
                            <relationship-data>
                                <relationship-key>model-ver.model-version-id</relationship-key>
                                <relationship-value>c00563ae-812b-4e62-8330-7c4d0f47088a</relationship-value>
                            </relationship-data>
                            <relationship-data>
                                <relationship-key>model.model-invariant-id</relationship-key>
                                <relationship-value>ef86f9c5-2165-44f3-8fc3-96018b609ea5</relationship-value>
                            </relationship-data>
                        </relationship>
                    </relationship-list>
                </model-element>
            </model-elements>
        </model-ver>
    </model-vers>
</model>|
2019-08-30T10:49:41.333Z|98fe1d6d-35e3-456a-8106-f5c7bda90cf7|pool-2-thread-1|ModelLoader|Event-Bus|AAIRESTClient||INFO|AC0001I|AC0001I PUT request at url = https://aai.onap:8443/aai/v16/service-design-and-creation/models/model/a96a90f0-e4bf-4b07-af17-689cece2d7a3|
2019-08-30T10:49:41.598Z|98fe1d6d-35e3-456a-8106-f5c7bda90cf7|pool-2-thread-1|ModelLoader|Event-Bus|AAIRESTClient||INFO|AC0003I|AC0003I PUT request operation time = 265 ms for link = https://aai.onap:8443/aai/v16/service-design-and-creation/models/model/a96a90f0-e4bf-4b07-af17-689cece2d7a3|
2019-08-30T10:49:41.599Z|98fe1d6d-35e3-456a-8106-f5c7bda90cf7|pool-2-thread-1|ModelLoader|Event-Bus|AAIRESTClient||INFO|AC0004I|AC0004I request at url = https://aai.onap:8443/aai/v16/service-design-and-creation/models/model/a96a90f0-e4bf-4b07-af17-689cece2d7a3 resulted in http response: 404 Not Found|

2019-08-30T10:49:41.600Z|98fe1d6d-35e3-456a-8106-f5c7bda90cf7|pool-2-thread-1|ModelLoader|Event-Bus|org.onap.aai.modelloader.entity.model.AbstractModelArtifact||ERROR|MDLSVC2002E|MDLSVC2002E Distribution event error: Ingestion failed for MODEL a96a90f0-e4bf-4b07-af17-689cece2d7a3|34e46a2b-d3c3-41b1-9c05-3231e2880e51 Error creating model. Skipping ingestion.. Rolling back distribution.|

2019-08-30T10:49:41.601Z|98fe1d6d-35e3-456a-8106-f5c7bda90cf7|pool-2-thread-1|ModelLoader|Event-Bus|org.onap.sdc.impl.DistributionClientImpl||INFO|DistributionClient - sendDeploymentStatus
2019-08-30T10:49:41.601Z|98fe1d6d-35e3-456a-8106-f5c7bda90cf7|pool-2-thread-1|ModelLoader|Event-Bus|org.onap.sdc.impl.DistributionClientImpl||INFO|DistributionClient - sendStatus
2019-08-30T10:49:41.705Z||pool-65-thread-1|ModelLoader||com.att.nsa.cambria.client.impl.CambriaSimplerBatchPublisher||INFO|sending 1 msgs to /events/SDC-DISTR-STATUS-TOPIC-AUTO. Oldest: 101 ms
2019-08-30T10:49:41.707Z||pool-65-thread-1|ModelLoader||com.att.nsa.apiClient.http.HttpClient||WARN|POST http://message-router.onap:3904/events/SDC-DISTR-STATUS-TOPIC-AUTO will send credentials over a clear channel.
2019-08-30T10:49:41.708Z||pool-65-thread-1|ModelLoader||com.att.nsa.apiClient.http.HttpClient||INFO|POST http://message-router.onap:3904/events/SDC-DISTR-STATUS-TOPIC-AUTO (as T9sEk3sr8ivLd7m5) ...
2019-08-30T10:49:41.749Z||pool-65-thread-1|ModelLoader||com.att.nsa.apiClient.http.HttpClient||INFO| --> HTTP/1.1 200 OK
2019-08-30T10:49:41.749Z||pool-65-thread-1|ModelLoader||com.att.nsa.cambria.client.impl.CambriaSimplerBatchPublisher||INFO|cambria reply ok (42 ms):{"serverTimeMs":0,"count":1}
2019-08-30T10:49:42.611Z|98fe1d6d-35e3-456a-8106-f5c7bda90cf7|pool-2-thread-1|ModelLoader|Event-Bus|org.onap.sdc.impl.DistributionClientImpl||INFO|DistributionClient - sendComponentDone status with errorReason
2019-08-30T10:49:42.611Z|98fe1d6d-35e3-456a-8106-f5c7bda90cf7|pool-2-thread-1|ModelLoader|Event-Bus|org.onap.sdc.impl.DistributionClientImpl||INFO|DistributionClient - sendStatus
2019-08-30T10:49:42.717Z||pool-66-thread-1|ModelLoader||com.att.nsa.cambria.client.impl.CambriaSimplerBatchPublisher||INFO|sending 1 msgs to /events/SDC-DISTR-STATUS-TOPIC-AUTO. Oldest: 101 ms
2019-08-30T10:49:42.718Z||pool-66-thread-1|ModelLoader||com.att.nsa.apiClient.http.HttpClient||WARN|POST http://message-router.onap:3904/events/SDC-DISTR-STATUS-TOPIC-AUTO will send credentials over a clear channel.
2019-08-30T10:49:42.718Z||pool-66-thread-1|ModelLoader||com.att.nsa.apiClient.http.HttpClient||INFO|POST http://message-router.onap:3904/events/SDC-DISTR-STATUS-TOPIC-AUTO (as T9sEk3sr8ivLd7m5) ...
2019-08-30T10:49:42.738Z||pool-66-thread-1|ModelLoader||com.att.nsa.apiClient.http.HttpClient||INFO| --> HTTP/1.1 200 OK
2019-08-30T10:49:42.738Z||pool-66-thread-1|ModelLoader||com.att.nsa.cambria.client.impl.CambriaSimplerBatchPublisher||INFO|cambria reply ok (21 ms):{"serverTimeMs":0,"count":1}
2019-08-30T10:49:53.312Z||pool-2-thread-1|ModelLoader||com.att.nsa.cambria.client.impl.CambriaConsumerImpl||INFO|UEB GET /events/SDC-DISTR-NOTIF-TOPIC-AUTO/aai-ml-group/aai-ml
2019-08-30T10:49:53.313Z||pool-2-thread-1|ModelLoader||com.att.nsa.apiClient.http.HttpClient||WARN|GET http://message-router.onap:3904/events/SDC-DISTR-NOTIF-TOPIC-AUTO/aai-ml-group/aai-ml will send credentials over a clear channel.
2019-08-30T10:49:53.313Z||pool-2-thread-1|ModelLoader||com.att.nsa.apiClient.http.HttpClient||INFO|GET http://message-router.onap:3904/events/SDC-DISTR-NOTIF-TOPIC-AUTO/aai-ml-group/aai-ml (as T9sEk3sr8ivLd7m5) ...
2019-08-30T10:50:03.144Z||pool-2-thread-1|ModelLoader||com.att.nsa.apiClient.http.HttpClient||INFO| --> HTTP/1.1 200 OK
2019-08-30T10:50:23.312Z||pool-2-thread-1|ModelLoader||com.att.nsa.cambria.client.impl.CambriaConsumerImpl||INFO|UEB GET /events/SDC-DISTR-NOTIF-TOPIC-AUTO/aai-ml-group/aai-ml
2019-08-30T10:50:23.313Z||pool-2-thread-1|ModelLoader||com.att.nsa.apiClient.http.HttpClient||WARN|GET http://message-router.onap:3904/events/SDC-DISTR-NOTIF-TOPIC-AUTO/aai-ml-group/aai-ml will send credentials over a clear channel.
2019-08-30T10:50:23.313Z||pool-2-thread-1|ModelLoader||com.att.nsa.apiClient.http.HttpClient||INFO|GET http://message-router.onap:3904/events/SDC-DISTR-NOTIF-TOPIC-AUTO/aai-ml-group/aai-ml (as T9sEk3sr8ivLd7m5) ...
2019-08-30T10:50:32.983Z||pool-2-thread-1|ModelLoader||com.att.nsa.apiClient.http.HttpClient||INFO| --> HTTP/1.1 200 OK
2019-08-30T10:50:53.313Z||pool-2-thread-1|ModelLoader||com.att.nsa.cambria.client.impl.CambriaConsumerImpl||INFO|UEB GET /events/SDC-DISTR-NOTIF-TOPIC-AUTO/aai-ml-group/aai-ml
2019-08-30T10:50:53.317Z||pool-2-thread-1|ModelLoader||com.att.nsa.apiClient.http.HttpClient||WARN|GET http://message-router.onap:3904/events/SDC-DISTR-NOTIF-TOPIC-AUTO/aai-ml-group/aai-ml will send credentials over a clear channel.
2019-08-30T10:50:53.317Z||pool-2-thread-1|ModelLoader||com.att.nsa.apiClient.http.HttpClient||INFO|GET http://message-router.onap:3904/events/SDC-DISTR-NOTIF-TOPIC-AUTO/aai-ml-group/aai-ml (as T9sEk3sr8ivLd7m5) ...
2019-08-30T10:51:03.050Z||pool-2-thread-1|ModelLoader||com.att.nsa.apiClient.http.HttpClient||INFO| --> HTTP/1.1 200 OK
2019-08-30T10:51:23.313Z||pool-2-thread-1|ModelLoader||com.att.nsa.cambria.client.impl.CambriaConsumerImpl||INFO|UEB GET /events/SDC-DISTR-NOTIF-TOPIC-AUTO/aai-ml-group/aai-ml
2019-08-30T10:51:23.314Z||pool-2-thread-1|ModelLoader||com.att.nsa.apiClient.http.HttpClient||WARN|GET http://message-router.onap:3904/events/SDC-DISTR-NOTIF-TOPIC-AUTO/aai-ml-group/aai-ml will send credentials over a clear channel.
2019-08-30T10:51:23.314Z||pool-2-thread-1|ModelLoader||com.att.nsa.apiClient.http.HttpClient||INFO|GET http://message-router.onap:3904/events/SDC-DISTR-NOTIF-TOPIC-AUTO/aai-ml-group/aai-ml (as T9sEk3sr8ivLd7m5) ...
2019-08-30T10:51:33.100Z||pool-2-thread-1|ModelLoader||com.att.nsa.apiClient.http.HttpClient||INFO| --> HTTP/1.1 200 OK
2019-08-30T10:51:53.312Z||pool-2-thread-1|ModelLoader||com.att.nsa.cambria.client.impl.CambriaConsumerImpl||INFO|UEB GET /events/SDC-DISTR-NOTIF-TOPIC-AUTO/aai-ml-group/aai-ml
2019-08-30T10:51:53.313Z||pool-2-thread-1|ModelLoader||com.att.nsa.apiClient.http.HttpClient||WARN|GET http://message-router.onap:3904/events/SDC-DISTR-NOTIF-TOPIC-AUTO/aai-ml-group/aai-ml will send credentials over a clear channel.
2019-08-30T10:51:53.313Z||pool-2-thread-1|ModelLoader||com.att.nsa.apiClient.http.HttpClient||INFO|GET http://message-router.onap:3904/events/SDC-DISTR-NOTIF-TOPIC-AUTO/aai-ml-group/aai-ml (as T9sEk3sr8ivLd7m5) ...
2019-08-30T10:52:03.069Z||pool-2-thread-1|ModelLoader||com.att.nsa.apiClient.http.HttpClient||INFO| --> HTTP/1.1 200 OK
2019-08-30T10:52:23.313Z||pool-2-thread-1|ModelLoader||com.att.nsa.cambria.client.impl.CambriaConsumerImpl||INFO|UEB GET /events/SDC-DISTR-NOTIF-TOPIC-AUTO/aai-ml-group/aai-ml
2019-08-30T10:52:23.314Z||pool-2-thread-1|ModelLoader||com.att.nsa.apiClient.http.HttpClient||WARN|GET http://message-router.onap:3904/events/SDC-DISTR-NOTIF-TOPIC-AUTO/aai-ml-group/aai-ml will send credentials over a clear channel.
2019-08-30T10:52:23.314Z||pool-2-thread-1|ModelLoader||com.att.nsa.apiClient.http.HttpClient||INFO|GET http://message-router.onap:3904/events/SDC-DISTR-NOTIF-TOPIC-AUTO/aai-ml-group/aai-ml (as T9sEk3sr8ivLd7m5) ...
2019-08-30T10:52:33.071Z||pool-2-thread-1|ModelLoader||com.att.nsa.apiClient.http.HttpClient||INFO| --> HTTP/1.1 200 OK

AAI Resources log snippet

2019-08-30T10:49:41.494+0000|2019-08-30T10:49:41.510+0000|98fe1d6d-35e3-456a-8106-f5c7bda90cf7||qtp1781071780-2602||PUT /aai/v16/service-design-and-creation/models/model/a96a90f0-e4bf-4b07-af17-689cece2d7a3|ModelLoader|COMPLETE||||DEBUG||10.42.3.6|16|aai-resources||org.onap.aai.extensions.ExtensionController|||||||co=ModelLoader:Extension class not found: org.onap.aai.extensions.v16.serviceDesignAndCreation.ModelExtension, method: DynamicAddServiceDesignAndCreationModelsModelPreProc.
2019-08-30T10:53:17.527+0000|2019-08-30T10:53:17.541+0000|030e9a24-5cf8-48c0-a4bd-3c80b1a4d6b9||qtp1781071780-2403||PUT /aai/v16/service-design-and-creation/models/model/a96a90f0-e4bf-4b07-af17-689cece2d7a3|ModelLoader|COMPLETE||||DEBUG||10.42.3.6|14|aai-resources||org.onap.aai.extensions.ExtensionController|||||||co=ModelLoader:Extension class not found: org.onap.aai.extensions.v16.serviceDesignAndCreation.ModelExtension, method: DynamicAddServiceDesignAndCreationModelsModelPreProc.
2019-08-30T10:55:38.556+0000|2019-08-30T10:55:38.572+0000|1b38537b-a8c2-47ff-bc0a-ca1e58cc200b||qtp1781071780-2613||PUT /aai/v16/service-design-and-creation/models/model/982253a5-781d-4071-845a-189c3fafe7a5|ModelLoader|COMPLETE||||DEBUG||10.42.3.6|16|aai-resources||org.onap.aai.extensions.ExtensionController|||||||co=ModelLoader:Extension class not found: org.onap.aai.extensions.v16.serviceDesignAndCreation.ModelExtension, method: DynamicAddServiceDesignAndCreationModelsModelPreProc.
2019-08-30T11:04:07.273+0000|2019-08-30T11:04:07.283+0000|ff9e0310-553f-44e9-8ce3-6129f2ae7569||qtp1781071780-2649||PUT /aai/v16/service-design-and-creation/models/model/d497f79c-254a-4351-89e8-c14ae2f21149|ModelLoader|COMPLETE||||DEBUG||10.42.3.6|10|aai-resources||org.onap.aai.extensions.ExtensionController|||||||co=ModelLoader:Extension class not found: org.onap.aai.extensions.v16.serviceDesignAndCreation.ModelExtension, method: DynamicAddServiceDesignAndCreationModelsModelPreProc.
2019-08-30T11:04:26.997+0000|2019-08-30T11:04:27.011+0000|96a60f30-d01b-4814-90d1-6bf1bd5a578b||qtp1781071780-2632||PUT /aai/v16/service-design-and-creation/models/model/a96a90f0-e4bf-4b07-af17-689cece2d7a3|ModelLoader|COMPLETE||||DEBUG||10.42.3.6|14|aai-resources||org.onap.aai.extensions.ExtensionController|||||||co=ModelLoader:Extension class not found: org.onap.aai.extensions.v16.serviceDesignAndCreation.ModelExtension, method: DynamicAddServiceDesignAndCreationModelsModelPreProc.

[NBI] nbi-mariadb in CrashLoop

DV
 

nbi-mariadb pod is failing continuously with CrashLoop.
Below are the logs. Any inputs appreciated!

2019-08-30 8:22:46 139736668686080 [Note] InnoDB: Loading buffer pool(s) from /var/lib/mysql/ib_buffer_pool
2019-08-30 8:22:46 139736668686080 [Note] InnoDB: Cannot open '/var/lib/mysql/ib_buffer_pool' for reading: No such file or directory
2019-08-30 8:22:46 139737765434688 [Note] Plugin 'FEEDBACK' is disabled.
2019-08-30 8:22:46 139737765434688 [ERROR] Could not open mysql.plugin table. Some plugins may be not loaded
2019-08-30 8:22:46 139737765434688 [Note] Recovering after a crash using tc.log
2019-08-30 8:22:46 139737765434688 [Note] Starting crash recovery...
2019-08-30 8:22:46 139737765434688 [Note] Crash recovery finished.
2019-08-30 8:22:46 139737765434688 [ERROR] Can't open and lock privilege tables: Table 'mysql.servers' doesn't exist
2019-08-30 8:22:46 139737765434688 [Note] Server socket created on IP: '::'.
2019-08-30 8:22:46 139737129969408 [Note] mysqld (initiated by: unknown): Normal shutdown
2019-08-30 8:22:46 139737765434688 [ERROR] Fatal error: Can't open and lock privilege tables: Table 'mysql.user' doesn't exist

Re: ONAP deployment on AWS #casablanca

Pritesh Gupta
 

Hi Marco,

Thanks for reply. Yes i will be using DevStack to deploy VNF. Just wanted some help to understand if its right way to deploy Onap Casablanca using OOM on AWS or there is also alternate way to do so. AWS EFS is facing some issue while deploying later modules of ONAP.

Also wanted to check which version is stable to perform basic vFW demo of ONAP. I tried to deploy Dublin but OOM doesnt have AAI charts in it. Hence need some help with links or documents that will guide to deploy required modules for vFW demo.

Re: [NBI]-Dublin Release - could not open mysql.plugin table

DV
 

I am having similar issue. 
Any inputs?

Re: Jenkins/Gerrit downtime planned 4pm-5pm PT Wed Aug28

Jessica Wagantall
 

This is now completed and services are back. 

thanks !
Jess

On Thu, Aug 29, 2019 at 4:10 PM Jessica Wagantall <jwagantall@...> wrote:
Waiting on 3 more jobs to complete and then I will shutdown Gerrit. 

Thanks for your patience!
Jess

On Thu, Aug 29, 2019 at 3:48 PM Jessica Wagantall <jwagantall@...> wrote:
Dear ONAP team, 

As mentioned in the TSC meeting, this downtime is about to happen.
Jenkins has been set to quietDown mode. 

Will let you know once the repo rename is done. 

thanks!
Jess

On Wed, Aug 28, 2019 at 4:41 PM Jessica Wagantall via Lists.Onap.Org <jwagantall=linuxfoundation.org@...> wrote:
My apologies,  the correct date for this is Aug 29th (tomorrow) from 4pm to 5pm

Thanks!
Jess

On Wed, Aug 28, 2019 at 3:54 PM Jessica Wagantall via Lists.Onap.Org <jwagantall=linuxfoundation.org@...> wrote:
Dear ONAP team, 

We are planning a downtime of Gerrit and Jenkins tomorrow between 4 and 5 pm PT time. 
This is in order to support a modeling repo renaming which can only be done in the server itself
in the current Gerrit version. 

Jenkins will be in quiet mode and Gerrit will be not accessible during that time.
 Feel free to use the APAC Gerrit mirror though which is READ-ONLY
            Example clone:
                    git clone git://gerrit-mirror-ap.onap.org/mirror/ci-management.git 

This plan will be reminded tomorrow in the TSC 
Thanks!
Jess

Re: Jenkins/Gerrit downtime planned 4pm-5pm PT Wed Aug28

Jessica Wagantall
 

Waiting on 3 more jobs to complete and then I will shutdown Gerrit. 

Thanks for your patience!
Jess

On Thu, Aug 29, 2019 at 3:48 PM Jessica Wagantall <jwagantall@...> wrote:
Dear ONAP team, 

As mentioned in the TSC meeting, this downtime is about to happen.
Jenkins has been set to quietDown mode. 

Will let you know once the repo rename is done. 

thanks!
Jess

On Wed, Aug 28, 2019 at 4:41 PM Jessica Wagantall via Lists.Onap.Org <jwagantall=linuxfoundation.org@...> wrote:
My apologies,  the correct date for this is Aug 29th (tomorrow) from 4pm to 5pm

Thanks!
Jess

On Wed, Aug 28, 2019 at 3:54 PM Jessica Wagantall via Lists.Onap.Org <jwagantall=linuxfoundation.org@...> wrote:
Dear ONAP team, 

We are planning a downtime of Gerrit and Jenkins tomorrow between 4 and 5 pm PT time. 
This is in order to support a modeling repo renaming which can only be done in the server itself
in the current Gerrit version. 

Jenkins will be in quiet mode and Gerrit will be not accessible during that time.
 Feel free to use the APAC Gerrit mirror though which is READ-ONLY
            Example clone:
                    git clone git://gerrit-mirror-ap.onap.org/mirror/ci-management.git 

This plan will be reminded tomorrow in the TSC 
Thanks!
Jess

Re: Jenkins/Gerrit downtime planned 4pm-5pm PT Wed Aug28

Jessica Wagantall
 

Dear ONAP team, 

As mentioned in the TSC meeting, this downtime is about to happen.
Jenkins has been set to quietDown mode. 

Will let you know once the repo rename is done. 

thanks!
Jess

On Wed, Aug 28, 2019 at 4:41 PM Jessica Wagantall via Lists.Onap.Org <jwagantall=linuxfoundation.org@...> wrote:
My apologies,  the correct date for this is Aug 29th (tomorrow) from 4pm to 5pm

Thanks!
Jess

On Wed, Aug 28, 2019 at 3:54 PM Jessica Wagantall via Lists.Onap.Org <jwagantall=linuxfoundation.org@...> wrote:
Dear ONAP team, 

We are planning a downtime of Gerrit and Jenkins tomorrow between 4 and 5 pm PT time. 
This is in order to support a modeling repo renaming which can only be done in the server itself
in the current Gerrit version. 

Jenkins will be in quiet mode and Gerrit will be not accessible during that time.
 Feel free to use the APAC Gerrit mirror though which is READ-ONLY
            Example clone:
                    git clone git://gerrit-mirror-ap.onap.org/mirror/ci-management.git 

This plan will be reminded tomorrow in the TSC 
Thanks!
Jess

#ccsdk team meeting cancelled this week (8/30) #ccsdk

TIMONEY, DAN
 

Cancelling this week’s CCSDK meeting .

 

Talk to you next week!

Dan

 

Dan Timoney

Principal Technical Staff Member

AT&T

Email : dtimoney@...

Office : +1 (732) 420-3226

Mobile : +1 (201) 960-1211

200 S Laurel Ave, Rm E2-2A03

Middletown, NJ 08873

Re: State of DMaaP AT&T legacy dependencies #dmaap #documentation

Krzysztof Opasiak
 

On 07.08.2019 16:58, Krzysztof Opasiak wrote:


On 07.08.2019 15:54, SAWANT, MANDAR wrote:
Please check now. The repositories have been restored.
I confirm that repos are again available. Thank you very much for that!

Would it be possible for you to push also release tags to the mentioned
repositories? Most of them don't have any of them which makes it very
hard to find and build some concrete version.
Ping?

Best regards,
--
Krzysztof Opasiak
Samsung R&D Institute Poland
Samsung Electronics

Re: vDNS use case / issue with SO pub about APPC-READ

Taka Cho
 

Looks like your shared NFS mount point has permission conflict with APPC helm’s staefulset.  

 

APPC DB Table creation will be triggered when APPC pod is starting.

 

Taka

 

From: Ferrero Marco Angelo <marco.ferrero@...>
Sent: Thursday, August 29, 2019 2:19 PM
To: onap-discuss@...; CHO, TAKAMUNE <tc012c@...>; PLATANIA, MARCO <platania@...>; D'Alessandro Alessandro Gerardo <alessandro.dalessandro@...>; VENKATESH KUMAR, VIJAY <vv770d@...>
Cc: MALAKOV, YURIY <ym9479@...>; Malinconico Aniello Paolo <a.malinconico@...>
Subject: R: vDNS use case / issue with SO pub about APPC-READ

 

Hi Taka,

thank you for your help.

I got the problem in the log of the appc

(command kubectl logs dev-appc-appc-0 -n onap -c appc)

 

+ /opt/onap/ccsdk/bin/installSdncDb.sh

Installing SDNC database

++ mysql -h appc-dbhost.onap -u root -psecretpassword mysql

+ appc_db_exists=

+ '[' x == x ']'

+ echo 'Installing APPC database'

+ /opt/onap/appc/bin/installAppcDb.sh

Installing APPC database

ERROR 1146 (42S02) at line 27: Table 'sdnctl.VNF_DG_MAPPING' doesn't exist

++ date

+ echo 'Installed at Thu Aug  8 14:30:36 UTC 2019'

/opt/appc/bin/startODL.sh: line 102: /opt/opendaylight/current/daexim/.installed: Permission denied

+ '[' '!' -f /opt/onap/ccsdk/.installed ']'

+ echo 'Installing ODL Host Key'

 

There is also a permission problem with the file /opt/opendaylight/current/daexim/.installed

 

APPC uses the image

 

Image:         nexus3.onap.org:10001/onap/appc-image:1.5.3

 

Re-executed script with command

mysql -usdnctl -pgamma -h appc-dbhost.onap sdnctl < /opt/onap/appc/data/sqlData.dump

gave in the appc container.

 

Here is the result:

 

MariaDB [sdnctl]> select * from VNF_DG_MAPPING;

+-------------------+------------------------+-------------+----------+-------------+-----------------+------------+-----------+

| VNF_DG_MAPPING_ID | ACTION                 | API_VERSION | VNF_TYPE | VNF_VERSION | DG_NAME         | DG_VERSION | DG_MODULE |

+-------------------+------------------------+-------------+----------+-------------+-----------------+------------+-----------+

|                 1 | Restart                | 2.00        |          |             | Generic_Restart | 3.0.0      | APPC      |

|                 2 | Configure              | NULL        | NULL     | NULL        | DGOrchestrator  | 4.0.0      | APPC      |

|                 3 | ConfigModify           | NULL        | NULL     | NULL        | DGOrchestrator  | 4.0.0      | APPC      |

|                 4 | Rebuild                | NULL        | NULL     | NULL        | DGOrchestrator  | 4.0.0      | APPC      |

|                 5 | Restart                | NULL        | NULL     | NULL        | DGOrchestrator  | 4.0.0      | APPC      |

|                 6 | HealthCheck            | NULL        | NULL     | NULL        | DGOrchestrator  | 4.0.0      | APPC      |

|                 7 | StartApplication       | NULL        | NULL     | NULL        | DGOrchestrator  | 4.0.0      | APPC      |

|                 8 | StopApplication        | NULL        | NULL     | NULL        | DGOrchestrator  | 4.0.0      | APPC      |

|                 9 | Migrate                | NULL        | NULL     | NULL        | DGOrchestrator  | 4.0.0      | APPC      |

|                10 | Snapshot               | NULL        | NULL     | NULL        | DGOrchestrator  | 4.0.0      | APPC      |

|                11 | ConfigRestore          | NULL        | NULL     | NULL        | DGOrchestrator  | 4.0.0      | APPC      |

|                12 | ConfigBackup           | NULL        | NULL     | NULL        | DGOrchestrator  | 4.0.0      | APPC      |

|                13 | Evacuate               | NULL        | NULL     | NULL        | DGOrchestrator  | 4.0.0      | APPC      |

|                14 | Stop                   | NULL        | NULL     | NULL        | DGOrchestrator  | 4.0.0      | APPC      |

|                15 | Start                  | NULL        | NULL     | NULL        | DGOrchestrator  | 4.0.0      | APPC      |

|                16 | ConfigScaleOut         | NULL        | NULL     | NULL        | DGOrchestrator  | 4.0.0      | APPC      |

|                17 | DistributeTraffic      | NULL        | NULL     | NULL        | DGOrchestrator  | 4.0.0      | APPC      |

|                18 | DistributeTrafficCheck | NULL        | NULL     | NULL        | DGOrchestrator  | 4.0.0      | APPC      |

+-------------------+------------------------+-------------+----------+-------------+-----------------+------------+-----------+

18 rows in set (0.00 sec)

 

Thank you.

 

Marco Ferrero

 

------------------------------------------------------------------
TIM

Marco Angelo Ferrero
Mobile & Fixed Innovation
IP, Transport & Core Innovation

TIM S.p.A.
Via G. Reiss Romoli, 274 – 10148 TORINO
+39 011 2286739
+39 331 6001354

 

Da: onap-discuss@... [mailto:onap-discuss@...] Per conto di Taka Cho
Inviato: giovedì 29 agosto 2019 17:23
A: Ferrero Marco Angelo; onap-discuss@...; PLATANIA, MARCO; D'Alessandro Alessandro Gerardo; VENKATESH KUMAR, VIJAY
Cc: MALAKOV, YURIY; Malinconico Aniello Paolo
Oggetto: [EXT] Re: [onap-discuss] vDNS use case / issue with SO pub about APPC-READ

 

VNF_DG_MAPPING table should not be empty after deploying APPC helm chart.

 

Here is the pre-load values for APPC DB

https://gerrit.onap.org/r/gitweb?p=appc/deployment.git;a=blob;f=installation/appc/src/main/resources/sqlData.dump;h=9d28eb53e78be42b9bef0f9e7ef01e195e215ef1;hb=9035495b03de1814d811f3a0c23959f55853616d

 

I think something is wrong when deploying APPC helm .. make sure you cleanup pv, pvc and remove the content for APPC on NFS share mount point.

 

Taka

 

From: Ferrero Marco Angelo <marco.ferrero@...>
Sent: Thursday, August 29, 2019 11:14 AM
To: onap-discuss@...; PLATANIA, MARCO <platania@...>; D'Alessandro Alessandro Gerardo <alessandro.dalessandro@...>; VENKATESH KUMAR, VIJAY <vv770d@...>
Cc: MALAKOV, YURIY <ym9479@...>; Malinconico Aniello Paolo <a.malinconico@...>; CHO, TAKAMUNE <tc012c@...>
Subject: R: vDNS use case / issue with SO pub about APPC-READ

 

Hi Marco,

We have sdnctl database both in

dev-mariadb-galera-mariadb-galera database (seem to be the master database of ONAP)

and

dev-appc-appc-db (APPC specific database).

 

In both cases all the tables whose name begin with VNF are empty.

Which of the two should I consider ?

 

Following I report the analisys of the appc database.

 

root@cp-1:~/oom/kubernetes# kubectl exec -n onap -ti dev-appc-appc-db-0 -- bash

bash-4.2$ mysql -usdnctl -pgamma

Welcome to the MariaDB monitor.  Commands end with ; or \g.

Your MariaDB connection id is 363170

Server version: 10.1.24-MariaDB MariaDB Server

 

Copyright (c) 2000, 2017, Oracle, MariaDB Corporation Ab and others.

 

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

 

MariaDB [(none)]> use sdnctl;

Reading table information for completion of table and column names

You can turn off this feature to get a quicker startup with -A

 

Database changed

MariaDB [sdnctl]> show tables like 'VNF%';

+-----------------------------+

| Tables_in_sdnctl (VNF%)     |

+-----------------------------+

| VNF                         |

| VNFC_DG_MAPPING             |

| VNFC_REFERENCE              |

| VNF_DG_MAPPING              |

| VNF_IMAGE                   |

| VNF_LOCK_MANAGEMENT         |

| VNF_MODEL_LICENSES          |

| VNF_MODEL_LICENSE_FEATURES  |

| VNF_NETWORKS                |

| VNF_NETWORK_CONNECTION      |

| VNF_NETWORK_CONNECTION_VLAN |

| VNF_PROFILE                 |

| VNF_STATE_MANAGEMENT        |

+-----------------------------+

13 rows in set (0.00 sec)

 

MariaDB [sdnctl]> describe VNF_DG_MAPPING;

+-------------------+--------------+------+-----+---------+----------------+

| Field             | Type         | Null | Key | Default | Extra          |

+-------------------+--------------+------+-----+---------+----------------+

| VNF_DG_MAPPING_ID | int(11)      | NO   | PRI | NULL    | auto_increment |

| ACTION            | varchar(50)  | NO   |     | NULL    |                |

| API_VERSION       | varchar(50)  | YES  |     | NULL    |                |

| VNF_TYPE          | varchar(150) | YES  |     | NULL    |                |

| VNF_VERSION       | varchar(50)  | YES  |     | NULL    |                |

| DG_NAME           | varchar(50)  | NO   |     | NULL    |                |

| DG_VERSION        | varchar(50)  | YES  |     | NULL    |                |

| DG_MODULE         | varchar(50)  | NO   |     | NULL    |                |

+-------------------+--------------+------+-----+---------+----------------+

8 rows in set (0.00 sec)

 

MariaDB [sdnctl]> select * from VNF_DG_MAPPING;

Empty set (0.00 sec)

 

Table empty as you wrote in your response Marco Platania.

 

Looking at the appc-db helm config:

 

  appc-db:

    Container ID:   docker://1c7944555847290b74553ed53245cf28ff457c5d45585b192369b8cc59255d1c

    Image:          nexus3.onap.org:10001/adfinissygroup/k8s-mariadb-galera-centos:v002

    Image ID:       docker-pullable://nexus3.onap.org:10001/adfinissygroup/k8s-mariadb-galera-centos@sha256:fbcb842f30065ae94532cb1af9bb03cc6e2acaaf896d87d0ec38da7dd09a3dde

    Ports:          3306/TCP, 4444/TCP, 4567/TCP, 4568/TCP

    Host Ports:     0/TCP, 0/TCP, 0/TCP, 0/TCP

    State:          Running

      Started:      Thu, 08 Aug 2019 14:24:37 +0000

    Ready:          True

    Restart Count:  0

    Liveness:       exec [mysqladmin ping] delay=60s timeout=5s period=10s #success=1 #failure=3

    Readiness:      exec [/usr/share/container-scripts/mysql/readiness-probe.sh] delay=30s timeout=5s period=10s #success=1 #failure=3

    Environment:

      POD_NAMESPACE:        onap (v1:metadata.namespace)

      MYSQL_USER:           my-user

      MYSQL_PASSWORD:       <set to the key 'user-password' in secret 'dev-appc-appc-db'>  Optional: false

      MYSQL_DATABASE:       my-database

      MYSQL_ROOT_PASSWORD:  <set to the key 'db-root-password' in secret 'dev-appc-appc-db'>  Optional: false

    Mounts:

      /etc/localtime from localtime (ro)

      /var/lib/mysql from dev-appc-appc-db-data (rw)

      /var/run/secrets/kubernetes.io/serviceaccount from default-token-wvnv6 (ro)

Conditions:

  Type              Status

  Initialized       True

  Ready             True

  ContainersReady   True

  PodScheduled      True

 

It mounts db in the directory /var/lib/mysql from the persistent volume named dev-appc-appc-db-data.

Persistent volumes are correctly set as you can see from the following command.

 

root@cp-1:~/oom/kubernetes# kubectl get pv -n onap | grep 'NAME\|dev-appc-appc-db-data'

NAME                                           CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS      CLAIM                                                                               STORAGECLASS                               REASON   AGE

dev-appc-appc-db-data0                         2Gi        RWX            Retain           Bound       onap/dev-appc-appc-db-data-dev-appc-appc-db-1                                       dev-appc-appc-db-data                               21d

dev-appc-appc-db-data1                         2Gi        RWX            Retain           Bound       onap/dev-appc-appc-db-data-dev-appc-appc-db-0                                       dev-appc-appc-db-data                               21d

dev-appc-appc-db-data2                         2Gi        RWX            Retain           Bound       onap/dev-appc-appc-db-data-dev-appc-appc-db-2                                       dev-appc-appc-db-data                               21d

 

Unfortunately I was not able to locate the job that populates this databases. It does not appear in these ones:

 

root@cp-1:~/oom/kubernetes# kubectl get jobs -n onap

NAME                                       COMPLETIONS   DURATION   AGE

dev-aaf-aaf-sms-preload                    1/1           4m16s      21d

dev-aaf-aaf-sshsm-distcenter               1/1           12s        21d

dev-aaf-aaf-sshsm-testca                   1/1           25s        21d

dev-aai-aai-graphadmin-create-db-schema    1/1           14m        21d

dev-aai-aai-traversal-update-query-data    1/1           22m        21d

dev-contrib-netbox-app-provisioning        1/1           4m46s      21d

dev-oof-music-cassandra-job-config         1/1           12m        21d

dev-oof-oof-has-healthcheck                1/1           24m        21d

dev-oof-oof-has-onboard                    1/1           23m        21d

dev-pnda-dcae-pnda-bootstrap               1/1           4m19s      21d

dev-portal-portal-db-config                1/1           11m        21d

dev-sdc-sdc-be-config-backend              1/1           20m        20d

dev-sdc-sdc-cs-config-cassandra            1/1           81s        20d

dev-sdc-sdc-dcae-be-tools                  1/1           27m        20d

dev-sdc-sdc-es-config-elasticsearch        1/1           4m38s      20d

dev-sdc-sdc-onboarding-be-cassandra-init   1/1           3m22s      20d

dev-sdc-sdc-wfd-be-workflow-init           1/1           3m42s      20d

dev-so-so-mariadb-config-job               1/1           4m50s      21d

dev-vid-vid-galera-config                  1/1           7m28s      21d

dev-vnfsdk-vnfsdk-init-postgres            1/1           15m        21d

 

root@cp-1:~/oom/kubernetes# kubectl get jobs -n onap | grep appc

 

All jobs are completed so it’s all ok.

As you can see no one refers to appc even if there are some jobs that initialize aai, portal, so, vid and vnfsdk databases.

We would greatly appreciate if you can indicate us the job that populates the appc db.

 

Thank you a lot.

 

Marco Ferrero

Alessandro D’Alessadro

------------------------------------------------------------------
TIM

Marco Angelo Ferrero
Mobile & Fixed Innovation
IP, Transport & Core Innovation

TIM S.p.A.
Via G. Reiss Romoli, 274 – 10148 TORINO
+39 011 2286739
+39 331 6001354

 

Da: onap-discuss@... [mailto:onap-discuss@...] Per conto di Marco Platania
Inviato: mercoledì 28 agosto 2019 19:56
A: D'Alessandro Alessandro Gerardo; VENKATESH KUMAR, VIJAY;
onap-discuss@...
Cc: MALAKOV, YURIY; Malinconico Aniello Paolo; Ferrero Marco Angelo; CHO, TAKAMUNE
Oggetto: [EXT] Re: [onap-discuss] vDNS use case / issue with SO pub about APPC-READ

 

Error 1 may be a symptom that the APPC DB hasn’t been populated correctly when it was installed. Connect to the sdnctl DB (user sdnctl, pwd gamma) and see if the VNF_TO_DG_MAPPING table has entries. If not, something went wrong during the DB installation. You may try to fix it by inserting the VNF to DG mappings manually (see SQL code below), but there’s a chance that other tables haven’t been populated as well, so you may have more problems later on.

 

insert into VNF_DG_MAPPING (VNF_DG_MAPPING_ID, ACTION, API_VERSION, VNF_TYPE, VNF_VERSION, DG_NAME, DG_VERSION, DG_MODULE) values

(1, 'Restart', '2.00', '', '', 'Generic_Restart', '3.0.0', 'APPC'),

(2, 'Configure', NULL, NULL, NULL, 'DGOrchestrator', '4.0.0', 'APPC'),

(3, 'ConfigModify', NULL, NULL, NULL, 'DGOrchestrator', '4.0.0', 'APPC'),

(4, 'Rebuild', NULL, NULL, NULL, 'DGOrchestrator', '4.0.0', 'APPC'),

(5, 'Restart', NULL, NULL, NULL, 'DGOrchestrator', '4.0.0', 'APPC'),

(6, 'HealthCheck', NULL, NULL, NULL, 'DGOrchestrator', '4.0.0', 'APPC'),

(7, 'StartApplication', NULL, NULL, NULL, 'DGOrchestrator', '4.0.0', 'APPC'),

(8, 'StopApplication', NULL, NULL, NULL, 'DGOrchestrator', '4.0.0', 'APPC'),

(9, 'Migrate', NULL, NULL, NULL, 'DGOrchestrator', '4.0.0', 'APPC'),

(10, 'Snapshot', NULL, NULL, NULL, 'DGOrchestrator', '4.0.0', 'APPC'),

(11, 'ConfigRestore', NULL, NULL, NULL, 'DGOrchestrator', '4.0.0', 'APPC'),

(12, 'ConfigBackup', NULL, NULL, NULL, 'DGOrchestrator', '4.0.0', 'APPC'),

(13, 'Evacuate', NULL, NULL, NULL, 'DGOrchestrator', '4.0.0', 'APPC'),

(14, 'Stop', NULL, NULL, NULL, 'DGOrchestrator', '4.0.0', 'APPC'),

(15, 'Start', NULL, NULL, NULL, 'DGOrchestrator', '4.0.0', 'APPC'),

(16, 'ConfigScaleOut', NULL, NULL, NULL, 'DGOrchestrator', '4.0.0', 'APPC'),

(17, 'DistributeTraffic', NULL, NULL, NULL, 'DGOrchestrator', '4.0.0', 'APPC'),

(18, 'DistributeTrafficCheck', NULL, NULL, NULL, 'DGOrchestrator', '4.0.0', 'APPC');

 

Error 2 is not a real issue, that topic isn’t used in ONAP. Error 4 is innocuous as well, please disregard it.

 

Error 3 I don’t know honestly, it seems a logging/permission issue. Not sure how bad it is, but I wouldn’t be surprised if it’s another symptom that something went wrong during APPC instantiation.

 

 

Taka,

 

Can you please add more on this? For what regards error 1, is it possible to re-run only the job that populates the DB, or should one rebuild APPC from scratch?

 

Thanks,

Marco

 

 

 

From: D'Alessandro Alessandro Gerardo <alessandro.dalessandro@...>
Date: Wednesday, August 28, 2019 at 12:32 PM
To: "PLATANIA, MARCO (MARCO)" <
platania@...>, "VENKATESH KUMAR, VIJAY" <vv770d@...>, "onap-discuss@..." <onap-discuss@...>
Cc: "MALAKOV, YURIY" <
ym9479@...>, Malinconico Aniello Paolo <a.malinconico@...>, Ferrero Marco Angelo <marco.ferrero@...>
Subject: RE: vDNS use case / issue with SO pub about APPC-READ

 

Hi Marco,

Error about “future timestamp” in the APPC log has been fixed synchronizing all k8s VMs. Thanks.

ONAP was able to read data from APPC-LCM-READ topic.

 

Unfortunately other errors appeared in the APPC logs.

 

Error 1: Error message (in the attached file) appears when a message from the topic APPC-LCM-READ has been consumed. AAI query works fine but the type of the VNF is set to vLoadBalancer_20190821/null". Could be the “/null” the cause?

Subsequently, in the same attached log, the VNF HealthCheck operation fails.

 

 

Error2: we get the error  ":"No such topic exists.-[APPC-CL]". Could you provide us with some details about such topic?

Which ONAP component writes the DMaaP topic APPC-CL ?

What are the difference of use between APPC-LCM-READ and APPC-CL  as both seem to be read by the APPC?

2019-08-28 09:47:37,750 | INFO  | Appc-Listener-2  | EventHandlerImpl                 | 426 - appc-common-bundle - 1.5.2 | Read 0 messages from APPC-CL as appcDemoEventListener/644.

2019-08-28 09:47:37,750 | INFO  | Appc-Listener-2  | EventHandlerImpl                 | 426 - appc-common-bundle - 1.5.2 | Getting up to 1000 incoming events

2019-08-28 09:47:37,751 | INFO  | Appc-Listener-2  | HttpDmaapConsumerImpl            | 426 - appc-common-bundle - 1.5.2 | GET http://message-router.onap:3904/events/APPC-CL/appcDemoEventListener/644?timeout=60000&limit=1000

2019-08-28 09:47:37,757 | ERROR | Appc-Listener-2  | HttpDmaapConsumerImpl            | 426 - appc-common-bundle - 1.5.2 | Did not get 200 from DMaaP. Got 404 - {"mrstatus":3001,"helpURL":"http://onap.readthedocs.io","message":"No such topic exists.-[APPC-CL]","status":404}

2019-08-28 09:47:37,757 | INFO  | Appc-Listener-2  | HttpDmaapConsumerImpl            | 426 - appc-common-bundle - 1.5.2 | Sleeping for 60s after failed request

 

 

Error3: It is categorized like INFO (not ERROR) but  a stack trace appears. Could be something the affect the normal APPC operation?

2019-08-28 09:46:37,749 | INFO  | Appc-Listener-2  | HttpDmaapConsumerImpl            | 426 - appc-common-bundle - 1.5.2 | Sleeping for 60s after failed request

2019-08-28 09:46:53,498 | INFO  | Appc-Listener-1  | HttpDmaapConsumerImpl            | 426 - appc-common-bundle - 1.5.2 | Got 0 messages from DMaaP

2019-08-28 09:46:53,498 | INFO  | Appc-Listener-1  | EventHandlerImpl                 | 426 - appc-common-bundle - 1.5.2 | Read 0 messages from APPC-LCM-READ as APPC-EVENT-LISTENER-TEST/74.

2019-08-28 09:46:53,499 | INFO  | Appc-Listener-1  | EventHandlerImpl                 | 426 - appc-common-bundle - 1.5.2 | Getting up to 10 incoming events

2019-08-28 09:46:53,499 | INFO  | Appc-Listener-1  | HttpDmaapConsumerImpl            | 426 - appc-common-bundle - 1.5.2 | GET http://message-router.onap:3904/events/APPC-LCM-READ/APPC-EVENT-LISTENER-TEST/74?timeout=60000&limit=10

2019-08-28 09:47:34,971 | INFO  | s4j.pax.logging) | fileinstall                      | 7 - org.apache.felix.fileinstall - 3.6.4 | Unable to save configuration

java.io.FileNotFoundException: /opt/opendaylight/etc/org.ops4j.pax.logging.cfg (Read-only file system)

        at java.io.FileOutputStream.open0(Native Method) ~[?:?]

        at java.io.FileOutputStream.open(FileOutputStream.java:270) [?:?]

        at java.io.FileOutputStream.<init>(FileOutputStream.java:213) [?:?]

        at java.io.FileOutputStream.<init>(FileOutputStream.java:162) [?:?]

        at org.apache.felix.fileinstall.internal.ConfigInstaller.doConfigurationEvent(ConfigInstaller.java:186) [7:org.apache.felix.fileinstall:3.6.4]

        at org.apache.felix.fileinstall.internal.ConfigInstaller.configurationEvent(ConfigInstaller.java:129) [7:org.apache.felix.fileinstall:3.6.4]

        at org.apache.felix.cm.impl.ConfigurationManager$FireConfigurationEvent.sendEvent(ConfigurationManager.java:2090) [6:org.apache.felix.configadmin:1.8.16]

        at org.apache.felix.cm.impl.ConfigurationManager$FireConfigurationEvent.run(ConfigurationManager.java:2058) [6:org.apache.felix.configadmin:1.8.16]

        at org.apache.felix.cm.impl.UpdateThread.run0(UpdateThread.java:141) [6:org.apache.felix.configadmin:1.8.16]

        at org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:109) [6:org.apache.felix.configadmin:1.8.16]

        at java.lang.Thread.run(Thread.java:748) [?:?]

 

 

Error 4: this error highlights the lack of file blueprints-processor-adaptor.properties.

Once this error appears, APPC processing exits waiting for next request. Could be due to something that went wrong in the distribution or instantiation phase?

Could it be a bug of APPC release we are using i.e. Image: nexus3.onap.org:10001/onap/appc-image:1.5.3 ?

2019-08-28 09:47:53,601 | INFO  | Appc-Listener-1  | HttpDmaapConsumerImpl            | 426 - appc-common-bundle - 1.5.2 | Got 0 messages from DMaaP

2019-08-28 09:47:53,602 | INFO  | Appc-Listener-1  | EventHandlerImpl                 | 426 - appc-common-bundle - 1.5.2 | Read 0 messages from APPC-LCM-READ as APPC-EVENT-LISTENER-TEST/74.

2019-08-28 09:47:53,603 | INFO  | Appc-Listener-1  | EventHandlerImpl                 | 426 - appc-common-bundle - 1.5.2 | Getting up to 10 incoming events

2019-08-28 09:47:53,604 | INFO  | Appc-Listener-1  | HttpDmaapConsumerImpl            | 426 - appc-common-bundle - 1.5.2 | GET http://message-router.onap:3904/events/APPC-LCM-READ/APPC-EVENT-LISTENER-TEST/74?timeout=60000&limit=10

2019-08-28 09:48:05,969 | ERROR | pool-30-thread-1 | ConfigRestAdaptorServiceImpl     | 358 - wrap_file__opt_opendaylight_system_com_att_eelf_eelf-core_1.0.0_eelf-core-1.0.0.jar - 0.0.0 | Failed to load properties for file: {} blueprints-processor-adaptor.properties

java.io.FileNotFoundException: /blueprints-processor-adaptor.properties (No such file or directory)

        at java.io.FileInputStream.open0(Native Method) ~[?:?]

        at java.io.FileInputStream.open(FileInputStream.java:195) ~[?:?]

        at java.io.FileInputStream.<init>(FileInputStream.java:138) ~[?:?]

        at java.io.FileInputStream.<init>(FileInputStream.java:93) ~[?:?]

        at org.onap.ccsdk.features.rest.adaptor.service.ConfigRestAdaptorServiceImpl.doLoadFromPath(ConfigRestAdaptorServiceImpl.java:99) ~[?:?]

        at org.onap.ccsdk.features.rest.adaptor.service.ConfigRestAdaptorServiceImpl.loadProps(ConfigRestAdaptorServiceImpl.java:91) ~[?:?]

        at org.onap.ccsdk.features.rest.adaptor.service.ConfigRestAdaptorServiceImpl.lambda$new$0(ConfigRestAdaptorServiceImpl.java:60) ~[?:?]

        at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [?:?]

        at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308) [?:?]

        at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180) [?:?]

        at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294) [?:?]

        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:?]

        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:?]

        at java.lang.Thread.run(Thread.java:748) [?:?]

 

 

 

Thank you for the help.

Marco Ferrero

Alessandro D’Alessandro.

 

 

From: PLATANIA, MARCO (MARCO) [mailto:platania@...]
Sent: giovedì 22 agosto 2019 19:00
To: D'Alessandro Alessandro Gerardo <
alessandro.dalessandro@...>; VENKATESH KUMAR, VIJAY <vv770d@...>; onap-discuss@...
Cc: MALAKOV, YURIY <
ym9479@...>; Malinconico Aniello Paolo <a.malinconico@...>; Ferrero Marco Angelo <marco.ferrero@...>
Subject: [EXT] Re: vDNS use case / issue with SO pub about APPC-READ

 

Messages published in APPC-LCM-WRITE definitely come from APPC (unless you set the topics differently, which is not the common case). APPC reads from APP-LCM-READ (which is where clients like SO publish). Being APPC-LCM-WRITE a shared channel between APPC and possibly multiple clients, the originator ID is just to express which client sent the input message (in APP-LCM-READ). I believe this is why you see MSO as originator ID.

 

Regarding the actual error, I think your K8S cluster has some nodes out of sync. Try to see if the timestamps in the VMs (or physical hosts) are synchronized. I’m quite sure that’s not an ONAP-related issue.

 

Marco

 

From: D'Alessandro Alessandro Gerardo <alessandro.dalessandro@...>
Date: Thursday, August 22, 2019 at 11:42 AM
To: "PLATANIA, MARCO (MARCO)" <
platania@...>, "VENKATESH KUMAR, VIJAY" <vv770d@...>, "onap-discuss@..." <onap-discuss@...>
Cc: "MALAKOV, YURIY" <
ym9479@...>, Malinconico Aniello Paolo <a.malinconico@...>, Ferrero Marco Angelo <marco.ferrero@...>
Subject: vDNS use case / issue with SO pub about APPC-READ

 

Hi All,

we are continue working on vDNS use case (https://docs.onap.org/en/latest/submodules/integration.git/docs/docs_scaleout.html ) primarily focusing on closed loop aspects

we successfully carried out the following steps related to the above guide

“PART 1 - Service Definition and Onboarding”

“PART 2 - Scale Out Use Case Instantiation”

“PART 3 - Post Instantiation Operations”

“3-1 Using the VNF : vLB Manual Configuration”… skipped because it was carried out automatically  

“3-2 Updating AAI with VNF resources”

 

After this steps we see vPKG does NOT generates packets. Anyway making that working is not our primary goal at this stage.

We changed the TCA rules as “if packets are LESS than 2000 than call policy operation” and this rules is always satisfied in our case. In fact we have seen MSO publishing a topic “APPC-LCM-READ” asking for "action":"HealthCheck". Refer to attached file “APPC_LCM_READ_messagerouter”

 

In the APP-C log you can also find “InvalidInputException : Input Timestamp is of future” associated to the messages related to the topic “APPC-LCM-READ”. Refer to attached file “appc_log_errortimestamp”

 

Afterwards we have noticed under topic “APPC-LCM-WRITE”  the following  "message":"INVALID INPUT PARAMETER - Input Timestamp is of future = Thu Aug 22 10:28:58 GMT 2019"           followed by  the          

"message":"UNEXPECTED ERROR - java.lang.IllegalStateException". Refer to attached file “APPC_LCM_WRITE_messagerouter”. Such messages are apparently published by MSO because that is the name associated to the field "originator-id" while we expected it was published by APPC as we understood from the  GET http://message-router.onap:3904/events/APPC-LCM-WRITE found in “bpmn_debug_cut.log”).

 

In the MSO log you can find the following error “Error Message: Unable to invoke action : HealthCheck”. Refer to attached file “bpmn_debug_cut.log”

 

 

Do you have any suggestion how to fix such issue?

Is there any document describing the semantic of messages published from both MSO and APPC?

 

Thanks in advance

 

Best regards,

Alessandro

 

Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie.

This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks.

Rispetta l'ambiente. Non stampare questa mail se non è necessario.

 

Re: R: R: [EXT] Re: [onap-discuss] vDNS use case / issue with SO pub about APPC-READ

Mir, Adil Kamal
 

Marco,

 

Also are you able to run the DNS query manually?

 

Try something like this… the IP is of the vLB

 

ubuntu@regionone-onap-nf-20190827t172215759z-vpg-001:~$ dig @192.168.20.55 host1.dnsdemo.onap.org

 

; <<>> DiG 9.10.3-P4-Ubuntu <<>> @192.168.20.55 host1.dnsdemo.onap.org

; (1 server found)

;; global options: +cmd

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32012

;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 2

;; WARNING: recursion requested but not available

 

;; OPT PSEUDOSECTION:

; EDNS: version: 0, flags:; udp: 4096

;; QUESTION SECTION:

;host1.dnsdemo.onap.org.           IN     A

 

;; ANSWER SECTION:

host1.dnsdemo.onap.org.     604800 IN     A      10.0.100.101

 

;; AUTHORITY SECTION:

dnsdemo.onap.org.    604800 IN     NS     dnsdemo.onap.org.

 

;; ADDITIONAL SECTION:

dnsdemo.onap.org.    604800 IN     A      10.0.100.100

 

;; Query time: 3 msec

;; SERVER: 192.168.20.55#53(192.168.20.55)

;; WHEN: Thu Aug 29 17:30:22 UTC 2019

;; MSG SIZE  rcvd: 97

 

 

From: Ferrero Marco Angelo <marco.ferrero@...>
Date: Thursday, August 29, 2019 at 1:12 PM
To: "onap-discuss@..." <onap-discuss@...>, "Mir, Adil Kamal" <adil_kamal.mir@...>, "platania@..." <platania@...>, D'Alessandro Alessandro Gerardo <alessandro.dalessandro@...>, "VENKATESH KUMAR, VIJAY" <vv770d@...>
Cc: "MALAKOV, YURIY" <ym9479@...>, Malinconico Aniello Paolo <a.malinconico@...>, "CHO, TAKAMUNE" <tc012c@...>
Subject: [EXT]R: R: [EXT] Re: [onap-discuss] vDNS use case / issue with SO pub about APPC-READ

 

Hi Mir,

thanks to your help I found the exact point where the code breaks:

https://github.com/onap/so/blob/dublin/bpmn/so-bpmn-tasks/src/main/java/org/onap/so/client/sdnc/mapper/GeneralTopologyObjectMapper.java

 

It’s here at line 163

 

 

if (vfModule.getModelInfoVfModule() == null) {

   throw new MapperException("VF Module model info is null for " + vfModule.getVfModuleId());

} else {

   ... OTHER STUFF ...

}

 

 

So the PUT request doesn’t return the model info of the VF module valorized.

Could you resend me the response of the PUT request ?

 

I was not able to find the definition of the class.

org.onap.so.bpmn.servicedecomposition.bbobjects.VfModule

Someone knows the url on git or gerrit where it is available ?

 

Coming back to the vPkg generator analisys,

The output of the ifconfig command is the same of yours. Only the IPs change.

Also the Operating system version is quite similar. Ubuntu 16.04.3 LTS yours, Ubuntu 16.04.6 LTS ours.

I suppose the are some differences if the file /opt/v_packetgen_init.sh in the vPKG VM.

 

Could you send the content of your file /opt/v_packetgen_init.sh ?

 

What values of the fields

  • install_script_version
  • demo_artifacts_version

you used in the body of the POST request sent to SO in order to start the instantiation of the vPKG/vLB/vDNS closed-loop use case ?

Could you send them to us ?

 

Thank you. J

 

Marco Ferrero

------------------------------------------------------------------
TIM

Marco Angelo Ferrero
Mobile & Fixed Innovation
IP, Transport & Core Innovation

TIM S.p.A.
Via G. Reiss Romoli, 274 – 10148 TORINO
+39 011 2286739
+39 331 6001354

 

Da: onap-discuss@... [mailto:onap-discuss@...] Per conto di Mir, Adil Kamal
Inviato: giovedì 29 agosto 2019 17:56
A: Ferrero Marco Angelo; onap-discuss@...; platania@...; D'Alessandro Alessandro Gerardo; VENKATESH KUMAR, VIJAY
Cc: MALAKOV, YURIY; Malinconico Aniello Paolo; CHO, TAKAMUNE
Oggetto: Re: R: [EXT] Re: [onap-discuss] vDNS use case / issue with SO pub about APPC-READ

 

Hi Marco,

 

Yes seems like the vf-module being created in AAI is lacking the required model info, this is what I have in AAI:

 

https://{{host}}:30233/aai/v15/network/generic-vnfs/generic-vnf/0d57e81c-53cf-40a0-8cc1-ae2a255ae473/vf-modules

 

{

    "vf-module": [

        {

            "vf-module-id": "54c15368-108d-4350-9fc3-bee00bb2e17b",

            "vf-module-name": "RegionOne_ONAP-NF_20190827T172215759Z_vlb_Expansion_001",

            "heat-stack-id": "RegionOne_ONAP-NF_20190827T172215759Z_vlb_Expansion_001/681ee7c5-3906-434f-9722-12f6086dfe81",

           "orchestration-status": "Active",

            "is-base-vf-module": false,

            "automated-assignment": false,

            "resource-version": "1566927307195",

            "model-invariant-id": "cbdcabc4-18bf-4b12-a1cf-5483baad1563",

            "model-version-id": "bfda7ba8-4a30-4689-b662-1dc3c5abfe3d",

            "model-customization-id": "291d82cf-c5e4-418f-bbcf-371c65f9d2dd",

            "module-index": 0,

            "selflink": "restconf/config/GENERIC-RESOURCE-API:services/service/bcbaba23-249a-4a05-835b-8a9e2167f344/service-data/vnfs/vnf/0d57e81c-53cf-40a0-8cc1-ae2a255ae473/vnf-data/vf-modules/vf-module/54c15368-108d-4350-9fc3-bee00bb2e17b/vf-module-data/vf-module-topology/",

            "relationship-list": {

                "relationship": [

                    {

                        "related-to": "vserver",

                        "relationship-label": "org.onap.relationships.inventory.Uses",

                        "related-link": "/aai/v15/cloud-infrastructure/cloud-regions/cloud-region/CloudOwner/RegionOne/tenants/tenant/7320ec4a5b9d4589ba7c4412ccfd290f/vservers/vserver/725c37e0-5db2-4238-b06a-ef363bfb2840",

                        "relationship-data": [

                            {

                                "relationship-key": "cloud-region.cloud-owner",

                                "relationship-value": "CloudOwner"

                            },

                            {

                                "relationship-key": "cloud-region.cloud-region-id",

                                "relationship-value": "RegionOne"

                            },

                            {

                                "relationship-key": "tenant.tenant-id",

                                "relationship-value": "7320ec4a5b9d4589ba7c4412ccfd290f"

                            },

                            {

                                "relationship-key": "vserver.vserver-id",

                                "relationship-value": "725c37e0-5db2-4238-b06a-ef363bfb2840"

                            }

                        ],

                        "related-to-property": [

                            {

                                "property-key": "vserver.vserver-name",

                                "property-value": "RegionOne_ONAP-NF_20190827T172215759Z_vlb_001"

                            }

                        ]

                    }

                ]

            }

        },

        {

            "vf-module-id": "8835b9a0-38ce-4bce-abc8-8c98c2247c01",

            "vf-module-name": "RegionOne_ONAP-NF_20190827T172215759Z_base_template_Base_001",

            "heat-stack-id": "RegionOne_ONAP-NF_20190827T172215759Z_base_template_Base_001/991b2f7e-5686-4cb8-ae7f-d5147457e424",

            "orchestration-status": "Active",

            "is-base-vf-module": true,

            "automated-assignment": false,

            "resource-version": "1566926952182",

            "model-invariant-id": "d7b402b0-c30d-4b50-ac6b-cac01deb2788",

            "model-version-id": "7b1d387d-d77f-4dab-be11-8529f3c79936",

            "model-customization-id": "d4a8d05f-c477-40ab-b166-cfb1bf1b13f5",

            "module-index": 0,

            "selflink": "restconf/config/GENERIC-RESOURCE-API:services/service/bcbaba23-249a-4a05-835b-8a9e2167f344/service-data/vnfs/vnf/0d57e81c-53cf-40a0-8cc1-ae2a255ae473/vnf-data/vf-modules/vf-module/8835b9a0-38ce-4bce-abc8-8c98c2247c01/vf-module-data/vf-module-topology/"

        },

        {

            "vf-module-id": "94e2e415-c4a2-4a84-b252-3dd368c99829",

            "vf-module-name": "RegionOne_ONAP-NF_20190827T172215759Z_vdns_Expansion_001",

            "heat-stack-id": "RegionOne_ONAP-NF_20190827T172215759Z_vdns_Expansion_001/3a828c5b-b9d7-4dee-971d-9e1c7a6b36ef",

            "orchestration-status": "Active",

            "is-base-vf-module": false,

            "automated-assignment": false,

            "resource-version": "1566927326724",

            "model-invariant-id": "d90cc7c9-39a0-49b7-b8c5-4e65a168138d",

            "model-version-id": "296c94c5-8d6b-47a9-b571-ae5a28711508",

            "model-customization-id": "afb0c617-52cf-4d31-9362-8d1c60ab2729",

            "module-index": 0,

            "selflink": "restconf/config/GENERIC-RESOURCE-API:services/service/bcbaba23-249a-4a05-835b-8a9e2167f344/service-data/vnfs/vnf/0d57e81c-53cf-40a0-8cc1-ae2a255ae473/vnf-data/vf-modules/vf-module/94e2e415-c4a2-4a84-b252-3dd368c99829/vf-module-data/vf-module-topology/"

        },

        {

            "vf-module-id": "4b965f71-4d32-4c4f-9677-b01e42365865",

            "vf-module-name": "vfModuleName",

            "orchestration-status": "Inventoried",

            "is-base-vf-module": false,

            "automated-assignment": false,

            "resource-version": "1567092785202",

            "module-index": 0

        },

        {

            "vf-module-id": "4576013f-e4eb-4264-b557-5a475bdfaca4",

            "vf-module-name": "RegionOne_ONAP-NF_20190827T172215759Z_vpkg_Expansion_001",

            "heat-stack-id": "RegionOne_ONAP-NF_20190827T172215759Z_vpkg_Expansion_001/bb304b12-a01a-4e4f-8479-268e9a4ac8b5",

            "orchestration-status": "Active",

            "is-base-vf-module": false,

            "automated-assignment": false,

            "resource-version": "1566926970260",

            "model-invariant-id": "89d46387-a8aa-4ce3-ab81-bfcd0905c586",

            "model-version-id": "1c41be0c-c3ba-42d4-a922-797cc75fad46",

            "model-customization-id": "1cc381ed-c0a9-4d58-ab9f-a4cfc9ba6634",

            "module-index": 0,

            "selflink": "restconf/config/GENERIC-RESOURCE-API:services/service/bcbaba23-249a-4a05-835b-8a9e2167f344/service-data/vnfs/vnf/0d57e81c-53cf-40a0-8cc1-ae2a255ae473/vnf-data/vf-modules/vf-module/4576013f-e4eb-4264-b557-5a475bdfaca4/vf-module-data/vf-module-topology/"

        }

    ]

}

 

From a test class that I saw over here (https://github.com/onap/so/blob/master/bpmn/so-bpmn-tasks/src/test/java/org/onap/so/client/sdnc/mapper/VfModuleTopologyOperationRequestMapperTest.java

) I think its missing the vfModuleModelInvariantUuid, vfModuleModelName, vfModuleModelVersion, vfModuleModelUuid, vfModuleModelCustomizationUuid… but not sure why are these missing in the PUT request to AAI to begin with.

 

I have also attached the SO request which does have that model info.

 

For the rest of your questions,

 

Please, could you log into the vm that runs the vPKG  and send us

  • output of the ifconfig command
  • ubuntu@regionone-onap-nf-20190827t172215759z-vpg-001:~$ ifconfig
  • br0       Link encap:Ethernet  HWaddr fa:16:3e:00:00:20  
  •           inet addr:192.168.20.56  Bcast:192.168.20.255  Mask:255.255.255.0
  •           inet6 addr: fe80::2da:e7ff:fe12:729c/64 Scope:Link
  •           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
  •           RX packets:50569 errors:0 dropped:0 overruns:0 frame:0
  •           TX packets:1107 errors:0 dropped:0 overruns:0 carrier:0
  •           collisions:0 txqueuelen:1000 
  •           RX bytes:5761194 (5.7 MB)  TX bytes:167400 (167.4 KB)
  •  
  • eth0      Link encap:Ethernet  HWaddr fa:16:3e:e2:8d:42  
  •           inet addr:10.195.197.12  Bcast:10.195.197.255  Mask:255.255.255.0
  •           inet6 addr: fe80::f816:3eff:fee2:8d42/64 Scope:Link
  •           UP BROADCAST RUNNING MULTICAST  MTU:9000  Metric:1
  •           RX packets:58053 errors:0 dropped:4 overruns:0 frame:0
  •           TX packets:1172 errors:0 dropped:0 overruns:0 carrier:0
  •           collisions:0 txqueuelen:1000 
  •           RX bytes:7466836 (7.4 MB)  TX bytes:142087 (142.0 KB)
  •  
  • eth1      Link encap:Ethernet  HWaddr 00:da:e7:12:72:9c  
  •           inet6 addr: fe80::2da:e7ff:fe12:729c/64 Scope:Link
  •           UP BROADCAST RUNNING MULTICAST  MTU:9000  Metric:1
  •           RX packets:50574 errors:0 dropped:0 overruns:0 frame:0
  •           TX packets:58845 errors:0 dropped:0 overruns:0 carrier:0
  •           collisions:0 txqueuelen:1000 
  •           RX bytes:6469578 (6.4 MB)  TX bytes:6749092 (6.7 MB)
  •  
  • eth2      Link encap:Ethernet  HWaddr fa:16:3e:ff:f8:66  
  •           inet addr:10.0.101.39  Bcast:10.0.255.255  Mask:255.255.0.0
  •           inet6 addr: fe80::f816:3eff:feff:f866/64 Scope:Link
  •           UP BROADCAST RUNNING MULTICAST  MTU:9000  Metric:1
  •           RX packets:16 errors:0 dropped:0 overruns:0 frame:0
  •           TX packets:7 errors:0 dropped:0 overruns:0 carrier:0
  •           collisions:0 txqueuelen:1000 
  •           RX bytes:1296 (1.2 KB)  TX bytes:578 (578.0 B)
  •  
  • lo        Link encap:Local Loopback  
  •           inet addr:127.0.0.1  Mask:255.0.0.0
  •           inet6 addr: ::1/128 Scope:Host
  •           UP LOOPBACK RUNNING  MTU:65536  Metric:1
  •           RX packets:160 errors:0 dropped:0 overruns:0 frame:0
  •           TX packets:160 errors:0 dropped:0 overruns:0 carrier:0
  •           collisions:0 txqueuelen:1 
  •           RX bytes:11840 (11.8 KB)  TX bytes:11840 (11.8 KB)
  •  
  • tap111    Link encap:Ethernet  HWaddr 6e:63:3a:6c:9d:6f  
  •           inet6 addr: fe80::6c63:3aff:fe6c:9d6f/64 Scope:Link
  •           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
  •           RX packets:57725 errors:0 dropped:0 overruns:0 frame:0
  •           TX packets:23 errors:0 dropped:0 overruns:0 carrier:0
  •           collisions:0 txqueuelen:1000 
  •           RX bytes:6580650 (6.5 MB)  TX bytes:1798 (1.7 KB)

 

  • content of the file /etc/lsb-release
  • ubuntu@regionone-onap-nf-20190827t172215759z-vpg-001:~$ cat /etc/lsb-release
  • DISTRIB_ID=Ubuntu
  • DISTRIB_RELEASE=16.04
  • DISTRIB_CODENAME=xenial
  • DISTRIB_DESCRIPTION="Ubuntu 16.04.3 LTS"

 

 

I noticed that the vLB in particular was not coming up fine (some packages were not installed) when using Ubuntu 14.04. Also note that 10.195.197.12 is from our openstack public network and 10.0.101.39 from our OAM network that can reach the ONAP k8s hosts.

 

Thank you,

Adil Mir

 

From: Ferrero Marco Angelo <marco.ferrero@...>
Date: Thursday, August 29, 2019 at 11:05 AM
To: "onap-discuss@..." <onap-discuss@...>, "Mir, Adil Kamal" <adil_kamal.mir@...>, "platania@..." <platania@...>, D'Alessandro Alessandro Gerardo <alessandro.dalessandro@...>, "VENKATESH KUMAR, VIJAY" <vv770d@...>
Cc: "MALAKOV, YURIY" <ym9479@...>, Malinconico Aniello Paolo <a.malinconico@...>, "CHO, TAKAMUNE" <tc012c@...>
Subject: [EXT]R: [EXT] Re: [onap-discuss] vDNS use case / issue with SO pub about APPC-READ

 

Hi Mir,

 

reading the log file you have sent to us I suppose the error you sent to us is due to something missing in the AAI description of the VNF.

Observing the bpmn log the request API is:

 

2019-08-28T20:50:02.778Z|| o.o.so.logging.jaxrs.filter.PayloadLoggingFilter - Making PUT request to: https://aai.onap:8443/aai/v15/network/generic-vnfs/generic-vnf/0d57e81c-53cf-40a0-8cc1-ae2a255ae473/vf-modules/vf-module/37c24a9f-27b2-46cb-b94a-1df0372d1a6f

Request Headers: {Authorization=[Basic YWFpQGFhaS5vbmFwLm9yZzpkZW1vMTIzNDU2IQ==], X-FromAppId=[MSO], X-TransactionId=[], Accept=[application/json], Content-Type=[application/json], X-ONAP-RequestID=[0e896d09-5b4e-4466-baab-5f1b27f89ae2], X-ONAP-InvocationID=[0c906cd3-1fe4-4241-a801-4b0a1f867ff6], X-ONAP-PartnerName=[SO]}

 

This seem to be the body of the request

 

2019-08-28T20:50:02.779Z|| o.o.so.logging.jaxrs.filter.PayloadLoggingFilter - {"vf-module-id":"37c24a9f-27b2-46cb-b94a-1df0372d1a6f","vf-module-name":"vDNS-VM-02","orchestration-status":"Inventoried","module-index":0}

 

Seem a SO request done to the AAI.

 

Unfortunately the sent back by the AAI breaks the code of the sdnc client of the AAI

 

2019-08-28T20:50:03.149Z|| o.o.s.bpmn.infrastructure.aai.tasks.AAICreateTasks - VolumeGroup not found. Skipping Connect between VfModule and VolumeGroup

2019-08-28T20:50:03.149Z|| o.o.s.b.infrastructure.sdnc.tasks.SDNCAssignTasks - No volume group was found.

2019-08-28T20:50:03.151Z|| org.onap.so.client.exception.ExceptionBuilder - Exception occurred

org.onap.so.client.exception.MapperException: VF Module model info is null for 37c24a9f-27b2-46cb-b94a-1df0372d1a6f

         at org.onap.so.client.sdnc.mapper.GeneralTopologyObjectMapper.buildVfModuleInformation(GeneralTopologyObjectMapper.java:163)

         at org.onap.so.client.sdnc.mapper.VfModuleTopologyOperationRequestMapper.reqMapper(VfModuleTopologyOperationRequestMapper.java:112)

 

Please, can you query the AAI and send us its response ?

 

I tried to find the classes that appear in the stack trace by looking here

https://gerrit.onap.org/r/gitweb?p=so.git;a=tree;h=refs/heads/dublin;hb=refs/heads/dublin

but I was not able to find them.

Someone knows where are located these classes ?

 

In our case the packet generator doesn’t sends DNS queries once the service was instantiated so in order to test the closed-loop chain we negated the check condition. In other words we changed

receivedPacketsDelta GREATER_OR_EQUAL

to

receivedPacketDelta LESS

 

we still problems but we discovered in our installation that the sdnctl database has been created but a lot of tables were not populated. We hope to solve the problem once these tables will be correctly populated.

 

Now we analyze the packed generator in order to check of differences between our and your installation.

Last week we already noticed problems that are described in the mail attached to this message.

 

Please, could you log into the vm that runs the vPKG  and send us

  • output of the ifconfig command
  • content of the file /etc/lsb-release

 

Thank you for your help.

Best regards

 

Marco Ferrero

Alessandro D’Alessandro

 

 

------------------------------------------------------------------
TIM

Marco Angelo Ferrero
Mobile & Fixed Innovation
IP, Transport & Core Innovation

TIM S.p.A.
Via G. Reiss Romoli, 274 – 10148 TORINO
+39 011 2286739
+39 331 6001354

 

Da: onap-discuss@... [mailto:onap-discuss@...] Per conto di Mir, Adil Kamal
Inviato: mercoledì 28 agosto 2019 23:07
A: onap-discuss@...; platania@...; D'Alessandro Alessandro Gerardo; VENKATESH KUMAR, VIJAY
Cc: MALAKOV, YURIY; Malinconico Aniello Paolo; Ferrero Marco Angelo; CHO, TAKAMUNE
Oggetto: [EXT] Re: [onap-discuss] vDNS use case / issue with SO pub about APPC-READ

 

Hello Alessandro and Marco,

 

I hope you can help me with vDNS use case as well. I was able to go a bit further and have the following:

 

The packet generator is sending DNS queries as expected, and the threshold does get violated on TCA which fires an event of DCAE-CL, and therefore ending up with a SO action for scale out.

 

However, the SO request after successfully doing the vLB health check via APPC fails with the following status message:

        "requestStatus": {

            "requestState": "FAILED",

            "statusMessage": "STATUS: Exception in org.onap.so.bpmn.infrastructure.sdnc.tasks.SDNCAssignTasks.assignVfModule VF Module model info is null for 37c24a9f-27b2-46cb-b94a-1df0372d1a6f FLOW STATUS: UnassignVfModuleBB has failed. ROLLBACK STATUS: Failed to determine rollback error message.",

            "percentProgress": 100,

            "timestamp": "Wed, 28 Aug 2019 20:50:16 GMT"

        }

 

In SO logs I can see the following exception:

 

2019-08-28T20:50:02.779Z|| o.o.so.logging.jaxrs.filter.PayloadLoggingFilter - {"vf-module-id":"37c24a9f-27b2-46cb-b94a-1df0372d1a6f","vf-module-name":"vDNS-VM-02","orchestration-status":"Inventoried","module-index":0}

 

2019-08-28T20:50:03.149Z|| o.o.s.bpmn.infrastructure.aai.tasks.AAICreateTasks - VolumeGroup not found. Skipping Connect between VfModule and VolumeGroup

2019-08-28T20:50:03.149Z|| o.o.s.b.infrastructure.sdnc.tasks.SDNCAssignTasks - No volume group was found.

2019-08-28T20:50:03.151Z|| org.onap.so.client.exception.ExceptionBuilder - Exception occurred

org.onap.so.client.exception.MapperException: VF Module model info is null for 37c24a9f-27b2-46cb-b94a-1df0372d1a6f

       at org.onap.so.client.sdnc.mapper.GeneralTopologyObjectMapper.buildVfModuleInformation(GeneralTopologyObjectMapper.java:163)

       at org.onap.so.client.sdnc.mapper.VfModuleTopologyOperationRequestMapper.reqMapper(VfModuleTopologyOperationRequestMapper.java:112)

       at org.onap.so.client.orchestration.SDNCVfModuleResources.assignVfModule(SDNCVfModuleResources.java:57)

       at org.onap.so.bpmn.infrastructure.sdnc.tasks.SDNCAssignTasks.assignVfModule(SDNCAssignTasks.java:124)

       at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

       at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)

       at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

       at java.lang.reflect.Method.invoke(Method.java:498)

 

I am also attaching the full SO BPMN logs for your reference.

 

Any idea what am I missing?

 

Thanks,

Adil

 

From: <onap-discuss@...> on behalf of Marco Platania <platania@...>
Reply-To: "onap-discuss@..." <onap-discuss@...>, "platania@..." <platania@...>
Date: Wednesday, August 28, 2019 at 2:01 PM
To: D'Alessandro Alessandro Gerardo <alessandro.dalessandro@...>, "VENKATESH KUMAR, VIJAY" <vv770d@...>, "onap-discuss@..." <onap-discuss@...>
Cc: "MALAKOV, YURIY" <ym9479@...>, Malinconico Aniello Paolo <a.malinconico@...>, Ferrero Marco Angelo <marco.ferrero@...>, "CHO, TAKAMUNE" <tc012c@...>
Subject: [EXT]Re: [onap-discuss] vDNS use case / issue with SO pub about APPC-READ

 

Error 1 may be a symptom that the APPC DB hasn’t been populated correctly when it was installed. Connect to the sdnctl DB (user sdnctl, pwd gamma) and see if the VNF_TO_DG_MAPPING table has entries. If not, something went wrong during the DB installation. You may try to fix it by inserting the VNF to DG mappings manually (see SQL code below), but there’s a chance that other tables haven’t been populated as well, so you may have more problems later on.

 

insert into VNF_DG_MAPPING (VNF_DG_MAPPING_ID, ACTION, API_VERSION, VNF_TYPE, VNF_VERSION, DG_NAME, DG_VERSION, DG_MODULE) values

(1, 'Restart', '2.00', '', '', 'Generic_Restart', '3.0.0', 'APPC'),

(2, 'Configure', NULL, NULL, NULL, 'DGOrchestrator', '4.0.0', 'APPC'),

(3, 'ConfigModify', NULL, NULL, NULL, 'DGOrchestrator', '4.0.0', 'APPC'),

(4, 'Rebuild', NULL, NULL, NULL, 'DGOrchestrator', '4.0.0', 'APPC'),

(5, 'Restart', NULL, NULL, NULL, 'DGOrchestrator', '4.0.0', 'APPC'),

(6, 'HealthCheck', NULL, NULL, NULL, 'DGOrchestrator', '4.0.0', 'APPC'),

(7, 'StartApplication', NULL, NULL, NULL, 'DGOrchestrator', '4.0.0', 'APPC'),

(8, 'StopApplication', NULL, NULL, NULL, 'DGOrchestrator', '4.0.0', 'APPC'),

(9, 'Migrate', NULL, NULL, NULL, 'DGOrchestrator', '4.0.0', 'APPC'),

(10, 'Snapshot', NULL, NULL, NULL, 'DGOrchestrator', '4.0.0', 'APPC'),

(11, 'ConfigRestore', NULL, NULL, NULL, 'DGOrchestrator', '4.0.0', 'APPC'),

(12, 'ConfigBackup', NULL, NULL, NULL, 'DGOrchestrator', '4.0.0', 'APPC'),

(13, 'Evacuate', NULL, NULL, NULL, 'DGOrchestrator', '4.0.0', 'APPC'),

(14, 'Stop', NULL, NULL, NULL, 'DGOrchestrator', '4.0.0', 'APPC'),

(15, 'Start', NULL, NULL, NULL, 'DGOrchestrator', '4.0.0', 'APPC'),

(16, 'ConfigScaleOut', NULL, NULL, NULL, 'DGOrchestrator', '4.0.0', 'APPC'),

(17, 'DistributeTraffic', NULL, NULL, NULL, 'DGOrchestrator', '4.0.0', 'APPC'),

(18, 'DistributeTrafficCheck', NULL, NULL, NULL, 'DGOrchestrator', '4.0.0', 'APPC');

 

Error 2 is not a real issue, that topic isn’t used in ONAP. Error 4 is innocuous as well, please disregard it.

 

Error 3 I don’t know honestly, it seems a logging/permission issue. Not sure how bad it is, but I wouldn’t be surprised if it’s another symptom that something went wrong during APPC instantiation.

 

 

Taka,

 

Can you please add more on this? For what regards error 1, is it possible to re-run only the job that populates the DB, or should one rebuild APPC from scratch?

 

Thanks,

Marco

 

 

 

From: D'Alessandro Alessandro Gerardo <alessandro.dalessandro@...>
Date: Wednesday, August 28, 2019 at 12:32 PM
To: "PLATANIA, MARCO (MARCO)" <platania@...>, "VENKATESH KUMAR, VIJAY" <vv770d@...>, "onap-discuss@..." <onap-discuss@...>
Cc: "MALAKOV, YURIY" <ym9479@...>, Malinconico Aniello Paolo <a.malinconico@...>, Ferrero Marco Angelo <marco.ferrero@...>
Subject: RE: vDNS use case / issue with SO pub about APPC-READ

 

Hi Marco,

Error about “future timestamp” in the APPC log has been fixed synchronizing all k8s VMs. Thanks.

ONAP was able to read data from APPC-LCM-READ topic.

 

Unfortunately other errors appeared in the APPC logs.

 

Error 1: Error message (in the attached file) appears when a message from the topic APPC-LCM-READ has been consumed. AAI query works fine but the type of the VNF is set to vLoadBalancer_20190821/null". Could be the “/null” the cause?

Subsequently, in the same attached log, the VNF HealthCheck operation fails.

 

 

Error2: we get the error  ":"No such topic exists.-[APPC-CL]". Could you provide us with some details about such topic?

Which ONAP component writes the DMaaP topic APPC-CL ?

What are the difference of use between APPC-LCM-READ and APPC-CL  as both seem to be read by the APPC?

2019-08-28 09:47:37,750 | INFO  | Appc-Listener-2  | EventHandlerImpl                 | 426 - appc-common-bundle - 1.5.2 | Read 0 messages from APPC-CL as appcDemoEventListener/644.

2019-08-28 09:47:37,750 | INFO  | Appc-Listener-2  | EventHandlerImpl                 | 426 - appc-common-bundle - 1.5.2 | Getting up to 1000 incoming events

2019-08-28 09:47:37,751 | INFO  | Appc-Listener-2  | HttpDmaapConsumerImpl            | 426 - appc-common-bundle - 1.5.2 | GET http://message-router.onap:3904/events/APPC-CL/appcDemoEventListener/644?timeout=60000&limit=1000

2019-08-28 09:47:37,757 | ERROR | Appc-Listener-2  | HttpDmaapConsumerImpl            | 426 - appc-common-bundle - 1.5.2 | Did not get 200 from DMaaP. Got 404 - {"mrstatus":3001,"helpURL":"http://onap.readthedocs.io","message":"No such topic exists.-[APPC-CL]","status":404}

2019-08-28 09:47:37,757 | INFO  | Appc-Listener-2  | HttpDmaapConsumerImpl            | 426 - appc-common-bundle - 1.5.2 | Sleeping for 60s after failed request

 

 

Error3: It is categorized like INFO (not ERROR) but  a stack trace appears. Could be something the affect the normal APPC operation?

2019-08-28 09:46:37,749 | INFO  | Appc-Listener-2  | HttpDmaapConsumerImpl            | 426 - appc-common-bundle - 1.5.2 | Sleeping for 60s after failed request

2019-08-28 09:46:53,498 | INFO  | Appc-Listener-1  | HttpDmaapConsumerImpl            | 426 - appc-common-bundle - 1.5.2 | Got 0 messages from DMaaP

2019-08-28 09:46:53,498 | INFO  | Appc-Listener-1  | EventHandlerImpl                 | 426 - appc-common-bundle - 1.5.2 | Read 0 messages from APPC-LCM-READ as APPC-EVENT-LISTENER-TEST/74.

2019-08-28 09:46:53,499 | INFO  | Appc-Listener-1  | EventHandlerImpl                 | 426 - appc-common-bundle - 1.5.2 | Getting up to 10 incoming events

2019-08-28 09:46:53,499 | INFO  | Appc-Listener-1  | HttpDmaapConsumerImpl            | 426 - appc-common-bundle - 1.5.2 | GET http://message-router.onap:3904/events/APPC-LCM-READ/APPC-EVENT-LISTENER-TEST/74?timeout=60000&limit=10

2019-08-28 09:47:34,971 | INFO  | s4j.pax.logging) | fileinstall                      | 7 - org.apache.felix.fileinstall - 3.6.4 | Unable to save configuration

java.io.FileNotFoundException: /opt/opendaylight/etc/org.ops4j.pax.logging.cfg (Read-only file system)

        at java.io.FileOutputStream.open0(Native Method) ~[?:?]

        at java.io.FileOutputStream.open(FileOutputStream.java:270) [?:?]

        at java.io.FileOutputStream.<init>(FileOutputStream.java:213) [?:?]

        at java.io.FileOutputStream.<init>(FileOutputStream.java:162) [?:?]

        at org.apache.felix.fileinstall.internal.ConfigInstaller.doConfigurationEvent(ConfigInstaller.java:186) [7:org.apache.felix.fileinstall:3.6.4]

        at org.apache.felix.fileinstall.internal.ConfigInstaller.configurationEvent(ConfigInstaller.java:129) [7:org.apache.felix.fileinstall:3.6.4]

        at org.apache.felix.cm.impl.ConfigurationManager$FireConfigurationEvent.sendEvent(ConfigurationManager.java:2090) [6:org.apache.felix.configadmin:1.8.16]

        at org.apache.felix.cm.impl.ConfigurationManager$FireConfigurationEvent.run(ConfigurationManager.java:2058) [6:org.apache.felix.configadmin:1.8.16]

        at org.apache.felix.cm.impl.UpdateThread.run0(UpdateThread.java:141) [6:org.apache.felix.configadmin:1.8.16]

        at org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:109) [6:org.apache.felix.configadmin:1.8.16]

        at java.lang.Thread.run(Thread.java:748) [?:?]

 

 

Error 4: this error highlights the lack of file blueprints-processor-adaptor.properties.

Once this error appears, APPC processing exits waiting for next request. Could be due to something that went wrong in the distribution or instantiation phase?

Could it be a bug of APPC release we are using i.e. Image: nexus3.onap.org:10001/onap/appc-image:1.5.3 ?

2019-08-28 09:47:53,601 | INFO  | Appc-Listener-1  | HttpDmaapConsumerImpl            | 426 - appc-common-bundle - 1.5.2 | Got 0 messages from DMaaP

2019-08-28 09:47:53,602 | INFO  | Appc-Listener-1  | EventHandlerImpl                 | 426 - appc-common-bundle - 1.5.2 | Read 0 messages from APPC-LCM-READ as APPC-EVENT-LISTENER-TEST/74.

2019-08-28 09:47:53,603 | INFO  | Appc-Listener-1  | EventHandlerImpl                 | 426 - appc-common-bundle - 1.5.2 | Getting up to 10 incoming events

2019-08-28 09:47:53,604 | INFO  | Appc-Listener-1  | HttpDmaapConsumerImpl            | 426 - appc-common-bundle - 1.5.2 | GET http://message-router.onap:3904/events/APPC-LCM-READ/APPC-EVENT-LISTENER-TEST/74?timeout=60000&limit=10

2019-08-28 09:48:05,969 | ERROR | pool-30-thread-1 | ConfigRestAdaptorServiceImpl     | 358 - wrap_file__opt_opendaylight_system_com_att_eelf_eelf-core_1.0.0_eelf-core-1.0.0.jar - 0.0.0 | Failed to load properties for file: {} blueprints-processor-adaptor.properties

java.io.FileNotFoundException: /blueprints-processor-adaptor.properties (No such file or directory)

        at java.io.FileInputStream.open0(Native Method) ~[?:?]

        at java.io.FileInputStream.open(FileInputStream.java:195) ~[?:?]

        at java.io.FileInputStream.<init>(FileInputStream.java:138) ~[?:?]

        at java.io.FileInputStream.<init>(FileInputStream.java:93) ~[?:?]

        at org.onap.ccsdk.features.rest.adaptor.service.ConfigRestAdaptorServiceImpl.doLoadFromPath(ConfigRestAdaptorServiceImpl.java:99) ~[?:?]

        at org.onap.ccsdk.features.rest.adaptor.service.ConfigRestAdaptorServiceImpl.loadProps(ConfigRestAdaptorServiceImpl.java:91) ~[?:?]

        at org.onap.ccsdk.features.rest.adaptor.service.ConfigRestAdaptorServiceImpl.lambda$new$0(ConfigRestAdaptorServiceImpl.java:60) ~[?:?]

        at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [?:?]

        at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308) [?:?]

        at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180) [?:?]

        at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294) [?:?]

        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:?]

        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:?]

        at java.lang.Thread.run(Thread.java:748) [?:?]

 

 

 

Thank you for the help.

Marco Ferrero

Alessandro D’Alessandro.

 

 

From: PLATANIA, MARCO (MARCO) [mailto:platania@...]

Sent: giovedì 22 agosto 2019 19:00
To: D'Alessandro Alessandro Gerardo <alessandro.dalessandro@...>; VENKATESH KUMAR, VIJAY <vv770d@...>; onap-discuss@...
Cc: MALAKOV, YURIY <ym9479@...>; Malinconico Aniello Paolo <a.malinconico@...>; Ferrero Marco Angelo <marco.ferrero@...>
Subject: [EXT] Re: vDNS use case / issue with SO pub about APPC-READ

 

Messages published in APPC-LCM-WRITE definitely come from APPC (unless you set the topics differently, which is not the common case). APPC reads from APP-LCM-READ (which is where clients like SO publish). Being APPC-LCM-WRITE a shared channel between APPC and possibly multiple clients, the originator ID is just to express which client sent the input message (in APP-LCM-READ). I believe this is why you see MSO as originator ID.

 

Regarding the actual error, I think your K8S cluster has some nodes out of sync. Try to see if the timestamps in the VMs (or physical hosts) are synchronized. I’m quite sure that’s not an ONAP-related issue.

 

Marco

 

From: D'Alessandro Alessandro Gerardo <alessandro.dalessandro@...>
Date: Thursday, August 22, 2019 at 11:42 AM
To: "PLATANIA, MARCO (MARCO)" <
platania@...>, "VENKATESH KUMAR, VIJAY" <vv770d@...>, "onap-discuss@..." <onap-discuss@...>
Cc: "MALAKOV, YURIY" <
ym9479@...>, Malinconico Aniello Paolo <a.malinconico@...>, Ferrero Marco Angelo <marco.ferrero@...>
Subject: vDNS use case / issue with SO pub about APPC-READ

 

Hi All,

we are continue working on vDNS use case (https://docs.onap.org/en/latest/submodules/integration.git/docs/docs_scaleout.html ) primarily focusing on closed loop aspects



we successfully carried out the following steps related to the above guide

“PART 1 - Service Definition and Onboarding”

“PART 2 - Scale Out Use Case Instantiation”

“PART 3 - Post Instantiation Operations”

“3-1 Using the VNF : vLB Manual Configuration”… skipped because it was carried out automatically  

“3-2 Updating AAI with VNF resources”

 

After this steps we see vPKG does NOT generates packets. Anyway making that working is not our primary goal at this stage.

We changed the TCA rules as “if packets are LESS than 2000 than call policy operation” and this rules is always satisfied in our case. In fact we have seen MSO publishing a topic “APPC-LCM-READ” asking for "action":"HealthCheck". Refer to attached file “APPC_LCM_READ_messagerouter”

 

In the APP-C log you can also find “InvalidInputException : Input Timestamp is of future” associated to the messages related to the topic “APPC-LCM-READ”. Refer to attached file “appc_log_errortimestamp”

 

Afterwards we have noticed under topic “APPC-LCM-WRITE”  the following  "message":"INVALID INPUT PARAMETER - Input Timestamp is of future = Thu Aug 22 10:28:58 GMT 2019"           followed by  the          

"message":"UNEXPECTED ERROR - java.lang.IllegalStateException". Refer to attached file “APPC_LCM_WRITE_messagerouter”. Such messages are apparently published by MSO because that is the name associated to the field "originator-id" while we expected it was published by APPC as we understood from the  GET http://message-router.onap:3904/events/APPC-LCM-WRITE found in “bpmn_debug_cut.log”).

 

In the MSO log you can find the following error “Error Message: Unable to invoke action : HealthCheck”. Refer to attached file “bpmn_debug_cut.log”

 

 

Do you have any suggestion how to fix such issue?

Is there any document describing the semantic of messages published from both MSO and APPC?

 

Thanks in advance

 

Best regards,

Alessandro

 

Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie.

This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks.

Rispetta l'ambiente. Non stampare questa mail se non è necessario.

 


External Email: Please use caution when opening links and attachments / Courriel externe: Soyez prudent avec les liens et documents joints

 

 


External Email: Please use caution when opening links and attachments / Courriel externe: Soyez prudent avec les liens et documents joints


External Email: Please use caution when opening links and attachments / Courriel externe: Soyez prudent avec les liens et documents joints

Re: R: R: [EXT] Re: [onap-discuss] vDNS use case / issue with SO pub about APPC-READ

Mir, Adil Kamal
 

Hi,

 

I have attached the contents of the v_packetgen_init.sh script.

 

Also following are the install_script and demo_artifact versions used:

 

                     "install_script_version":"1.5.0-SNAPSHOT",

                     "demo_artifacts_version":"1.5.0-SNAPSHOT",

 

I am trying to find the response for that PUT request, any idea where I can look. I see the following in AAI resource REST logs:

 

root@aai-resources:/opt/app/aai-resources/logs/rest# cat debug.log

2019-08-29T15:28:13.697+0000|2019-08-29T15:28:13.700+0000|801b882e-9a45-4903-97a2-f82da8a21040||pool-5520-thread-1||GET /aai/v15/network/generic-vnfs/generic-vnf/0d57e81c-53cf-40a0-8cc1-ae2a255ae473/vf-modules/vf-module/vf-module-id/37c24a9f-27b2-46cb-b94a-1df0372d1a6f|RASHMI|COMPLETE||||DEBUG||10.42.4.24|3|aai-resources||org.onap.aai.introspection.MoxyLoader|||||||co=RASHMI:Unable to find 37c24a9f-27b2-46cb-b94a-1df0372d1a6f in the store for lower hyphen to upper camel

2019-08-29T15:29:06.443+0000|2019-08-29T15:29:06.583+0000|33c374e9-f277-4254-a26c-6cce8a94a810||qtp1781071780-29406||DELETE /aai/v15/network/generic-vnfs/generic-vnf/0d57e81c-53cf-40a0-8cc1-ae2a255ae473/vf-modules/vf-module/37c24a9f-27b2-46cb-b94a-1df0372d1a6f?resource-version=1567025402886|RASHMI|COMPLETE||||DEBUG||10.42.4.24|9|aai-resources||org.onap.aai.extensions.ExtensionController|||||||co=RASHMI:Extension class not found: org.onap.aai.extensions.v15.network.GenericVnfExtension, method: DynamicDelNetworkGenericVnfsGenericVnfVfModulesVfModulePreProc.

2019-08-29T15:29:06.443+0000|2019-08-29T15:29:06.628+0000|33c374e9-f277-4254-a26c-6cce8a94a810||qtp1781071780-29406||DELETE /aai/v15/network/generic-vnfs/generic-vnf/0d57e81c-53cf-40a0-8cc1-ae2a255ae473/vf-modules/vf-module/37c24a9f-27b2-46cb-b94a-1df0372d1a6f?resource-version=1567025402886|RASHMI|COMPLETE||||DEBUG||10.42.4.24|9|aai-resources||org.onap.aai.serialization.db.DBSerializer|||||||co=RASHMI:Removing vertex 303144 with label vertex

2019-08-29T15:29:06.443+0000|2019-08-29T15:29:06.668+0000|33c374e9-f277-4254-a26c-6cce8a94a810||qtp1781071780-29406||DELETE /aai/v15/network/generic-vnfs/generic-vnf/0d57e81c-53cf-40a0-8cc1-ae2a255ae473/vf-modules/vf-module/37c24a9f-27b2-46cb-b94a-1df0372d1a6f?resource-version=1567025402886|RASHMI|COMPLETE||||DEBUG||10.42.4.24|9|aai-resources||org.onap.aai.extensions.ExtensionController|||||||co=RASHMI:Extension class not found: org.onap.aai.extensions.v15.network.GenericVnfExtension, method: DynamicDelNetworkGenericVnfsGenericVnfVfModulesVfModulePostProc.

2019-08-29T15:33:05.202+0000|2019-08-29T15:33:05.239+0000|d4df1902-a092-4ad8-a4b9-e43509c47273||qtp1781071780-29439||PUT /aai/v15/network/generic-vnfs/generic-vnf/0d57e81c-53cf-40a0-8cc1-ae2a255ae473/vf-modules/vf-module/4b965f71-4d32-4c4f-9677-b01e42365865|MSO|COMPLETE||||DEBUG||10.42.4.24|37|aai-resources||org.onap.aai.extensions.ExtensionController|||||||co=MSO:Extension class not found: org.onap.aai.extensions.v15.network.GenericVnfExtension, method: DynamicAddNetworkGenericVnfsGenericVnfVfModulesVfModulePreProc.

2019-08-29T15:33:05.202+0000|2019-08-29T15:33:05.336+0000|d4df1902-a092-4ad8-a4b9-e43509c47273||qtp1781071780-29439||PUT /aai/v15/network/generic-vnfs/generic-vnf/0d57e81c-53cf-40a0-8cc1-ae2a255ae473/vf-modules/vf-module/4b965f71-4d32-4c4f-9677-b01e42365865|MSO|COMPLETE||||DEBUG||10.42.4.24|0|aai-resources||org.onap.aai.extensions.ExtensionController|||||||co=MSO:Extension class not found: org.onap.aai.extensions.v15.network.GenericVnfExtension, method: DynamicAddNetworkGenericVnfsGenericVnfVfModulesVfModulePostProc.

 

 

Thanks,

Adil

 

From: Ferrero Marco Angelo <marco.ferrero@...>
Date: Thursday, August 29, 2019 at 1:12 PM
To: "onap-discuss@..." <onap-discuss@...>, "Mir, Adil Kamal" <adil_kamal.mir@...>, "platania@..." <platania@...>, D'Alessandro Alessandro Gerardo <alessandro.dalessandro@...>, "VENKATESH KUMAR, VIJAY" <vv770d@...>
Cc: "MALAKOV, YURIY" <ym9479@...>, Malinconico Aniello Paolo <a.malinconico@...>, "CHO, TAKAMUNE" <tc012c@...>
Subject: [EXT]R: R: [EXT] Re: [onap-discuss] vDNS use case / issue with SO pub about APPC-READ

 

Hi Mir,

thanks to your help I found the exact point where the code breaks:

https://github.com/onap/so/blob/dublin/bpmn/so-bpmn-tasks/src/main/java/org/onap/so/client/sdnc/mapper/GeneralTopologyObjectMapper.java

 

It’s here at line 163

 

 

if (vfModule.getModelInfoVfModule() == null) {

   throw new MapperException("VF Module model info is null for " + vfModule.getVfModuleId());

} else {

   ... OTHER STUFF ...

}

 

 

So the PUT request doesn’t return the model info of the VF module valorized.

Could you resend me the response of the PUT request ?

 

I was not able to find the definition of the class.

org.onap.so.bpmn.servicedecomposition.bbobjects.VfModule

Someone knows the url on git or gerrit where it is available ?

 

Coming back to the vPkg generator analisys,

The output of the ifconfig command is the same of yours. Only the IPs change.

Also the Operating system version is quite similar. Ubuntu 16.04.3 LTS yours, Ubuntu 16.04.6 LTS ours.

I suppose the are some differences if the file /opt/v_packetgen_init.sh in the vPKG VM.

 

Could you send the content of your file /opt/v_packetgen_init.sh ?

 

What values of the fields

  • install_script_version
  • demo_artifacts_version

you used in the body of the POST request sent to SO in order to start the instantiation of the vPKG/vLB/vDNS closed-loop use case ?

Could you send them to us ?

 

Thank you. J

 

Marco Ferrero

------------------------------------------------------------------
TIM

Marco Angelo Ferrero
Mobile & Fixed Innovation
IP, Transport & Core Innovation

TIM S.p.A.
Via G. Reiss Romoli, 274 – 10148 TORINO
+39 011 2286739
+39 331 6001354

 

Da: onap-discuss@... [mailto:onap-discuss@...] Per conto di Mir, Adil Kamal
Inviato: giovedì 29 agosto 2019 17:56
A: Ferrero Marco Angelo; onap-discuss@...; platania@...; D'Alessandro Alessandro Gerardo; VENKATESH KUMAR, VIJAY
Cc: MALAKOV, YURIY; Malinconico Aniello Paolo; CHO, TAKAMUNE
Oggetto: Re: R: [EXT] Re: [onap-discuss] vDNS use case / issue with SO pub about APPC-READ

 

Hi Marco,

 

Yes seems like the vf-module being created in AAI is lacking the required model info, this is what I have in AAI:

 

https://{{host}}:30233/aai/v15/network/generic-vnfs/generic-vnf/0d57e81c-53cf-40a0-8cc1-ae2a255ae473/vf-modules

 

{

    "vf-module": [

        {

            "vf-module-id": "54c15368-108d-4350-9fc3-bee00bb2e17b",

            "vf-module-name": "RegionOne_ONAP-NF_20190827T172215759Z_vlb_Expansion_001",

            "heat-stack-id": "RegionOne_ONAP-NF_20190827T172215759Z_vlb_Expansion_001/681ee7c5-3906-434f-9722-12f6086dfe81",

           "orchestration-status": "Active",

            "is-base-vf-module": false,

            "automated-assignment": false,

            "resource-version": "1566927307195",

            "model-invariant-id": "cbdcabc4-18bf-4b12-a1cf-5483baad1563",

            "model-version-id": "bfda7ba8-4a30-4689-b662-1dc3c5abfe3d",

            "model-customization-id": "291d82cf-c5e4-418f-bbcf-371c65f9d2dd",

            "module-index": 0,

            "selflink": "restconf/config/GENERIC-RESOURCE-API:services/service/bcbaba23-249a-4a05-835b-8a9e2167f344/service-data/vnfs/vnf/0d57e81c-53cf-40a0-8cc1-ae2a255ae473/vnf-data/vf-modules/vf-module/54c15368-108d-4350-9fc3-bee00bb2e17b/vf-module-data/vf-module-topology/",

            "relationship-list": {

                "relationship": [

                    {

                        "related-to": "vserver",

                        "relationship-label": "org.onap.relationships.inventory.Uses",

                        "related-link": "/aai/v15/cloud-infrastructure/cloud-regions/cloud-region/CloudOwner/RegionOne/tenants/tenant/7320ec4a5b9d4589ba7c4412ccfd290f/vservers/vserver/725c37e0-5db2-4238-b06a-ef363bfb2840",

                        "relationship-data": [

                            {

                                "relationship-key": "cloud-region.cloud-owner",

                                "relationship-value": "CloudOwner"

                            },

                            {

                                "relationship-key": "cloud-region.cloud-region-id",

                                "relationship-value": "RegionOne"

                            },

                            {

                                "relationship-key": "tenant.tenant-id",

                                "relationship-value": "7320ec4a5b9d4589ba7c4412ccfd290f"

                            },

                            {

                                "relationship-key": "vserver.vserver-id",

                                "relationship-value": "725c37e0-5db2-4238-b06a-ef363bfb2840"

                            }

                        ],

                        "related-to-property": [

                            {

                                "property-key": "vserver.vserver-name",

                                "property-value": "RegionOne_ONAP-NF_20190827T172215759Z_vlb_001"

                            }

                        ]

                    }

                ]

            }

        },

        {

            "vf-module-id": "8835b9a0-38ce-4bce-abc8-8c98c2247c01",

            "vf-module-name": "RegionOne_ONAP-NF_20190827T172215759Z_base_template_Base_001",

            "heat-stack-id": "RegionOne_ONAP-NF_20190827T172215759Z_base_template_Base_001/991b2f7e-5686-4cb8-ae7f-d5147457e424",

            "orchestration-status": "Active",

            "is-base-vf-module": true,

            "automated-assignment": false,

            "resource-version": "1566926952182",

            "model-invariant-id": "d7b402b0-c30d-4b50-ac6b-cac01deb2788",

            "model-version-id": "7b1d387d-d77f-4dab-be11-8529f3c79936",

            "model-customization-id": "d4a8d05f-c477-40ab-b166-cfb1bf1b13f5",

            "module-index": 0,

            "selflink": "restconf/config/GENERIC-RESOURCE-API:services/service/bcbaba23-249a-4a05-835b-8a9e2167f344/service-data/vnfs/vnf/0d57e81c-53cf-40a0-8cc1-ae2a255ae473/vnf-data/vf-modules/vf-module/8835b9a0-38ce-4bce-abc8-8c98c2247c01/vf-module-data/vf-module-topology/"

        },

        {

            "vf-module-id": "94e2e415-c4a2-4a84-b252-3dd368c99829",

            "vf-module-name": "RegionOne_ONAP-NF_20190827T172215759Z_vdns_Expansion_001",

            "heat-stack-id": "RegionOne_ONAP-NF_20190827T172215759Z_vdns_Expansion_001/3a828c5b-b9d7-4dee-971d-9e1c7a6b36ef",

            "orchestration-status": "Active",

            "is-base-vf-module": false,

            "automated-assignment": false,

            "resource-version": "1566927326724",

            "model-invariant-id": "d90cc7c9-39a0-49b7-b8c5-4e65a168138d",

            "model-version-id": "296c94c5-8d6b-47a9-b571-ae5a28711508",

            "model-customization-id": "afb0c617-52cf-4d31-9362-8d1c60ab2729",

            "module-index": 0,

            "selflink": "restconf/config/GENERIC-RESOURCE-API:services/service/bcbaba23-249a-4a05-835b-8a9e2167f344/service-data/vnfs/vnf/0d57e81c-53cf-40a0-8cc1-ae2a255ae473/vnf-data/vf-modules/vf-module/94e2e415-c4a2-4a84-b252-3dd368c99829/vf-module-data/vf-module-topology/"

        },

        {

            "vf-module-id": "4b965f71-4d32-4c4f-9677-b01e42365865",

            "vf-module-name": "vfModuleName",

            "orchestration-status": "Inventoried",

            "is-base-vf-module": false,

            "automated-assignment": false,

            "resource-version": "1567092785202",

            "module-index": 0

        },

        {

            "vf-module-id": "4576013f-e4eb-4264-b557-5a475bdfaca4",

            "vf-module-name": "RegionOne_ONAP-NF_20190827T172215759Z_vpkg_Expansion_001",

            "heat-stack-id": "RegionOne_ONAP-NF_20190827T172215759Z_vpkg_Expansion_001/bb304b12-a01a-4e4f-8479-268e9a4ac8b5",

            "orchestration-status": "Active",

            "is-base-vf-module": false,

            "automated-assignment": false,

            "resource-version": "1566926970260",

            "model-invariant-id": "89d46387-a8aa-4ce3-ab81-bfcd0905c586",

            "model-version-id": "1c41be0c-c3ba-42d4-a922-797cc75fad46",

            "model-customization-id": "1cc381ed-c0a9-4d58-ab9f-a4cfc9ba6634",

            "module-index": 0,

            "selflink": "restconf/config/GENERIC-RESOURCE-API:services/service/bcbaba23-249a-4a05-835b-8a9e2167f344/service-data/vnfs/vnf/0d57e81c-53cf-40a0-8cc1-ae2a255ae473/vnf-data/vf-modules/vf-module/4576013f-e4eb-4264-b557-5a475bdfaca4/vf-module-data/vf-module-topology/"

        }

    ]

}

 

From a test class that I saw over here (https://github.com/onap/so/blob/master/bpmn/so-bpmn-tasks/src/test/java/org/onap/so/client/sdnc/mapper/VfModuleTopologyOperationRequestMapperTest.java

) I think its missing the vfModuleModelInvariantUuid, vfModuleModelName, vfModuleModelVersion, vfModuleModelUuid, vfModuleModelCustomizationUuid… but not sure why are these missing in the PUT request to AAI to begin with.

 

I have also attached the SO request which does have that model info.

 

For the rest of your questions,

 

Please, could you log into the vm that runs the vPKG  and send us

  • output of the ifconfig command
  • ubuntu@regionone-onap-nf-20190827t172215759z-vpg-001:~$ ifconfig
  • br0       Link encap:Ethernet  HWaddr fa:16:3e:00:00:20  
  •           inet addr:192.168.20.56  Bcast:192.168.20.255  Mask:255.255.255.0
  •           inet6 addr: fe80::2da:e7ff:fe12:729c/64 Scope:Link
  •           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
  •           RX packets:50569 errors:0 dropped:0 overruns:0 frame:0
  •           TX packets:1107 errors:0 dropped:0 overruns:0 carrier:0
  •           collisions:0 txqueuelen:1000 
  •           RX bytes:5761194 (5.7 MB)  TX bytes:167400 (167.4 KB)
  •  
  • eth0      Link encap:Ethernet  HWaddr fa:16:3e:e2:8d:42  
  •           inet addr:10.195.197.12  Bcast:10.195.197.255  Mask:255.255.255.0
  •           inet6 addr: fe80::f816:3eff:fee2:8d42/64 Scope:Link
  •           UP BROADCAST RUNNING MULTICAST  MTU:9000  Metric:1
  •           RX packets:58053 errors:0 dropped:4 overruns:0 frame:0
  •           TX packets:1172 errors:0 dropped:0 overruns:0 carrier:0
  •           collisions:0 txqueuelen:1000 
  •           RX bytes:7466836 (7.4 MB)  TX bytes:142087 (142.0 KB)
  •  
  • eth1      Link encap:Ethernet  HWaddr 00:da:e7:12:72:9c  
  •           inet6 addr: fe80::2da:e7ff:fe12:729c/64 Scope:Link
  •           UP BROADCAST RUNNING MULTICAST  MTU:9000  Metric:1
  •           RX packets:50574 errors:0 dropped:0 overruns:0 frame:0
  •           TX packets:58845 errors:0 dropped:0 overruns:0 carrier:0
  •           collisions:0 txqueuelen:1000 
  •           RX bytes:6469578 (6.4 MB)  TX bytes:6749092 (6.7 MB)
  •  
  • eth2      Link encap:Ethernet  HWaddr fa:16:3e:ff:f8:66  
  •           inet addr:10.0.101.39  Bcast:10.0.255.255  Mask:255.255.0.0
  •           inet6 addr: fe80::f816:3eff:feff:f866/64 Scope:Link
  •           UP BROADCAST RUNNING MULTICAST  MTU:9000  Metric:1
  •           RX packets:16 errors:0 dropped:0 overruns:0 frame:0
  •           TX packets:7 errors:0 dropped:0 overruns:0 carrier:0
  •           collisions:0 txqueuelen:1000 
  •           RX bytes:1296 (1.2 KB)  TX bytes:578 (578.0 B)
  •  
  • lo        Link encap:Local Loopback  
  •           inet addr:127.0.0.1  Mask:255.0.0.0
  •           inet6 addr: ::1/128 Scope:Host
  •           UP LOOPBACK RUNNING  MTU:65536  Metric:1
  •           RX packets:160 errors:0 dropped:0 overruns:0 frame:0
  •           TX packets:160 errors:0 dropped:0 overruns:0 carrier:0
  •           collisions:0 txqueuelen:1 
  •           RX bytes:11840 (11.8 KB)  TX bytes:11840 (11.8 KB)
  •  
  • tap111    Link encap:Ethernet  HWaddr 6e:63:3a:6c:9d:6f  
  •           inet6 addr: fe80::6c63:3aff:fe6c:9d6f/64 Scope:Link
  •           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
  •           RX packets:57725 errors:0 dropped:0 overruns:0 frame:0
  •           TX packets:23 errors:0 dropped:0 overruns:0 carrier:0
  •           collisions:0 txqueuelen:1000 
  •           RX bytes:6580650 (6.5 MB)  TX bytes:1798 (1.7 KB)

 

  • content of the file /etc/lsb-release
  • ubuntu@regionone-onap-nf-20190827t172215759z-vpg-001:~$ cat /etc/lsb-release
  • DISTRIB_ID=Ubuntu
  • DISTRIB_RELEASE=16.04
  • DISTRIB_CODENAME=xenial
  • DISTRIB_DESCRIPTION="Ubuntu 16.04.3 LTS"

 

 

I noticed that the vLB in particular was not coming up fine (some packages were not installed) when using Ubuntu 14.04. Also note that 10.195.197.12 is from our openstack public network and 10.0.101.39 from our OAM network that can reach the ONAP k8s hosts.

 

Thank you,

Adil Mir

 

From: Ferrero Marco Angelo <marco.ferrero@...>
Date: Thursday, August 29, 2019 at 11:05 AM
To: "onap-discuss@..." <onap-discuss@...>, "Mir, Adil Kamal" <adil_kamal.mir@...>, "platania@..." <platania@...>, D'Alessandro Alessandro Gerardo <alessandro.dalessandro@...>, "VENKATESH KUMAR, VIJAY" <vv770d@...>
Cc: "MALAKOV, YURIY" <ym9479@...>, Malinconico Aniello Paolo <a.malinconico@...>, "CHO, TAKAMUNE" <tc012c@...>
Subject: [EXT]R: [EXT] Re: [onap-discuss] vDNS use case / issue with SO pub about APPC-READ

 

Hi Mir,

 

reading the log file you have sent to us I suppose the error you sent to us is due to something missing in the AAI description of the VNF.

Observing the bpmn log the request API is:

 

2019-08-28T20:50:02.778Z|| o.o.so.logging.jaxrs.filter.PayloadLoggingFilter - Making PUT request to: https://aai.onap:8443/aai/v15/network/generic-vnfs/generic-vnf/0d57e81c-53cf-40a0-8cc1-ae2a255ae473/vf-modules/vf-module/37c24a9f-27b2-46cb-b94a-1df0372d1a6f

Request Headers: {Authorization=[Basic YWFpQGFhaS5vbmFwLm9yZzpkZW1vMTIzNDU2IQ==], X-FromAppId=[MSO], X-TransactionId=[], Accept=[application/json], Content-Type=[application/json], X-ONAP-RequestID=[0e896d09-5b4e-4466-baab-5f1b27f89ae2], X-ONAP-InvocationID=[0c906cd3-1fe4-4241-a801-4b0a1f867ff6], X-ONAP-PartnerName=[SO]}

 

This seem to be the body of the request

 

2019-08-28T20:50:02.779Z|| o.o.so.logging.jaxrs.filter.PayloadLoggingFilter - {"vf-module-id":"37c24a9f-27b2-46cb-b94a-1df0372d1a6f","vf-module-name":"vDNS-VM-02","orchestration-status":"Inventoried","module-index":0}

 

Seem a SO request done to the AAI.

 

Unfortunately the sent back by the AAI breaks the code of the sdnc client of the AAI

 

2019-08-28T20:50:03.149Z|| o.o.s.bpmn.infrastructure.aai.tasks.AAICreateTasks - VolumeGroup not found. Skipping Connect between VfModule and VolumeGroup

2019-08-28T20:50:03.149Z|| o.o.s.b.infrastructure.sdnc.tasks.SDNCAssignTasks - No volume group was found.

2019-08-28T20:50:03.151Z|| org.onap.so.client.exception.ExceptionBuilder - Exception occurred

org.onap.so.client.exception.MapperException: VF Module model info is null for 37c24a9f-27b2-46cb-b94a-1df0372d1a6f

         at org.onap.so.client.sdnc.mapper.GeneralTopologyObjectMapper.buildVfModuleInformation(GeneralTopologyObjectMapper.java:163)

         at org.onap.so.client.sdnc.mapper.VfModuleTopologyOperationRequestMapper.reqMapper(VfModuleTopologyOperationRequestMapper.java:112)

 

Please, can you query the AAI and send us its response ?

 

I tried to find the classes that appear in the stack trace by looking here

https://gerrit.onap.org/r/gitweb?p=so.git;a=tree;h=refs/heads/dublin;hb=refs/heads/dublin

but I was not able to find them.

Someone knows where are located these classes ?

 

In our case the packet generator doesn’t sends DNS queries once the service was instantiated so in order to test the closed-loop chain we negated the check condition. In other words we changed

receivedPacketsDelta GREATER_OR_EQUAL

to

receivedPacketDelta LESS

 

we still problems but we discovered in our installation that the sdnctl database has been created but a lot of tables were not populated. We hope to solve the problem once these tables will be correctly populated.

 

Now we analyze the packed generator in order to check of differences between our and your installation.

Last week we already noticed problems that are described in the mail attached to this message.

 

Please, could you log into the vm that runs the vPKG  and send us

  • output of the ifconfig command
  • content of the file /etc/lsb-release

 

Thank you for your help.

Best regards

 

Marco Ferrero

Alessandro D’Alessandro

 

 

------------------------------------------------------------------
TIM

Marco Angelo Ferrero
Mobile & Fixed Innovation
IP, Transport & Core Innovation

TIM S.p.A.
Via G. Reiss Romoli, 274 – 10148 TORINO
+39 011 2286739
+39 331 6001354

 

Da: onap-discuss@... [mailto:onap-discuss@...] Per conto di Mir, Adil Kamal
Inviato: mercoledì 28 agosto 2019 23:07
A: onap-discuss@...; platania@...; D'Alessandro Alessandro Gerardo; VENKATESH KUMAR, VIJAY
Cc: MALAKOV, YURIY; Malinconico Aniello Paolo; Ferrero Marco Angelo; CHO, TAKAMUNE
Oggetto: [EXT] Re: [onap-discuss] vDNS use case / issue with SO pub about APPC-READ

 

Hello Alessandro and Marco,

 

I hope you can help me with vDNS use case as well. I was able to go a bit further and have the following:

 

The packet generator is sending DNS queries as expected, and the threshold does get violated on TCA which fires an event of DCAE-CL, and therefore ending up with a SO action for scale out.

 

However, the SO request after successfully doing the vLB health check via APPC fails with the following status message:

        "requestStatus": {

            "requestState": "FAILED",

            "statusMessage": "STATUS: Exception in org.onap.so.bpmn.infrastructure.sdnc.tasks.SDNCAssignTasks.assignVfModule VF Module model info is null for 37c24a9f-27b2-46cb-b94a-1df0372d1a6f FLOW STATUS: UnassignVfModuleBB has failed. ROLLBACK STATUS: Failed to determine rollback error message.",

            "percentProgress": 100,

            "timestamp": "Wed, 28 Aug 2019 20:50:16 GMT"

        }

 

In SO logs I can see the following exception:

 

2019-08-28T20:50:02.779Z|| o.o.so.logging.jaxrs.filter.PayloadLoggingFilter - {"vf-module-id":"37c24a9f-27b2-46cb-b94a-1df0372d1a6f","vf-module-name":"vDNS-VM-02","orchestration-status":"Inventoried","module-index":0}

 

2019-08-28T20:50:03.149Z|| o.o.s.bpmn.infrastructure.aai.tasks.AAICreateTasks - VolumeGroup not found. Skipping Connect between VfModule and VolumeGroup

2019-08-28T20:50:03.149Z|| o.o.s.b.infrastructure.sdnc.tasks.SDNCAssignTasks - No volume group was found.

2019-08-28T20:50:03.151Z|| org.onap.so.client.exception.ExceptionBuilder - Exception occurred

org.onap.so.client.exception.MapperException: VF Module model info is null for 37c24a9f-27b2-46cb-b94a-1df0372d1a6f

       at org.onap.so.client.sdnc.mapper.GeneralTopologyObjectMapper.buildVfModuleInformation(GeneralTopologyObjectMapper.java:163)

       at org.onap.so.client.sdnc.mapper.VfModuleTopologyOperationRequestMapper.reqMapper(VfModuleTopologyOperationRequestMapper.java:112)

       at org.onap.so.client.orchestration.SDNCVfModuleResources.assignVfModule(SDNCVfModuleResources.java:57)

       at org.onap.so.bpmn.infrastructure.sdnc.tasks.SDNCAssignTasks.assignVfModule(SDNCAssignTasks.java:124)

       at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

       at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)

       at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

       at java.lang.reflect.Method.invoke(Method.java:498)

 

I am also attaching the full SO BPMN logs for your reference.

 

Any idea what am I missing?

 

Thanks,

Adil

 

From: <onap-discuss@...> on behalf of Marco Platania <platania@...>
Reply-To: "onap-discuss@..." <onap-discuss@...>, "platania@..." <platania@...>
Date: Wednesday, August 28, 2019 at 2:01 PM
To: D'Alessandro Alessandro Gerardo <alessandro.dalessandro@...>, "VENKATESH KUMAR, VIJAY" <vv770d@...>, "onap-discuss@..." <onap-discuss@...>
Cc: "MALAKOV, YURIY" <ym9479@...>, Malinconico Aniello Paolo <a.malinconico@...>, Ferrero Marco Angelo <marco.ferrero@...>, "CHO, TAKAMUNE" <tc012c@...>
Subject: [EXT]Re: [onap-discuss] vDNS use case / issue with SO pub about APPC-READ

 

Error 1 may be a symptom that the APPC DB hasn’t been populated correctly when it was installed. Connect to the sdnctl DB (user sdnctl, pwd gamma) and see if the VNF_TO_DG_MAPPING table has entries. If not, something went wrong during the DB installation. You may try to fix it by inserting the VNF to DG mappings manually (see SQL code below), but there’s a chance that other tables haven’t been populated as well, so you may have more problems later on.

 

insert into VNF_DG_MAPPING (VNF_DG_MAPPING_ID, ACTION, API_VERSION, VNF_TYPE, VNF_VERSION, DG_NAME, DG_VERSION, DG_MODULE) values

(1, 'Restart', '2.00', '', '', 'Generic_Restart', '3.0.0', 'APPC'),

(2, 'Configure', NULL, NULL, NULL, 'DGOrchestrator', '4.0.0', 'APPC'),

(3, 'ConfigModify', NULL, NULL, NULL, 'DGOrchestrator', '4.0.0', 'APPC'),

(4, 'Rebuild', NULL, NULL, NULL, 'DGOrchestrator', '4.0.0', 'APPC'),

(5, 'Restart', NULL, NULL, NULL, 'DGOrchestrator', '4.0.0', 'APPC'),

(6, 'HealthCheck', NULL, NULL, NULL, 'DGOrchestrator', '4.0.0', 'APPC'),

(7, 'StartApplication', NULL, NULL, NULL, 'DGOrchestrator', '4.0.0', 'APPC'),

(8, 'StopApplication', NULL, NULL, NULL, 'DGOrchestrator', '4.0.0', 'APPC'),

(9, 'Migrate', NULL, NULL, NULL, 'DGOrchestrator', '4.0.0', 'APPC'),

(10, 'Snapshot', NULL, NULL, NULL, 'DGOrchestrator', '4.0.0', 'APPC'),

(11, 'ConfigRestore', NULL, NULL, NULL, 'DGOrchestrator', '4.0.0', 'APPC'),

(12, 'ConfigBackup', NULL, NULL, NULL, 'DGOrchestrator', '4.0.0', 'APPC'),

(13, 'Evacuate', NULL, NULL, NULL, 'DGOrchestrator', '4.0.0', 'APPC'),

(14, 'Stop', NULL, NULL, NULL, 'DGOrchestrator', '4.0.0', 'APPC'),

(15, 'Start', NULL, NULL, NULL, 'DGOrchestrator', '4.0.0', 'APPC'),

(16, 'ConfigScaleOut', NULL, NULL, NULL, 'DGOrchestrator', '4.0.0', 'APPC'),

(17, 'DistributeTraffic', NULL, NULL, NULL, 'DGOrchestrator', '4.0.0', 'APPC'),

(18, 'DistributeTrafficCheck', NULL, NULL, NULL, 'DGOrchestrator', '4.0.0', 'APPC');

 

Error 2 is not a real issue, that topic isn’t used in ONAP. Error 4 is innocuous as well, please disregard it.

 

Error 3 I don’t know honestly, it seems a logging/permission issue. Not sure how bad it is, but I wouldn’t be surprised if it’s another symptom that something went wrong during APPC instantiation.

 

 

Taka,

 

Can you please add more on this? For what regards error 1, is it possible to re-run only the job that populates the DB, or should one rebuild APPC from scratch?

 

Thanks,

Marco

 

 

 

From: D'Alessandro Alessandro Gerardo <alessandro.dalessandro@...>
Date: Wednesday, August 28, 2019 at 12:32 PM
To: "PLATANIA, MARCO (MARCO)" <platania@...>, "VENKATESH KUMAR, VIJAY" <vv770d@...>, "onap-discuss@..." <onap-discuss@...>
Cc: "MALAKOV, YURIY" <ym9479@...>, Malinconico Aniello Paolo <a.malinconico@...>, Ferrero Marco Angelo <marco.ferrero@...>
Subject: RE: vDNS use case / issue with SO pub about APPC-READ

 

Hi Marco,

Error about “future timestamp” in the APPC log has been fixed synchronizing all k8s VMs. Thanks.

ONAP was able to read data from APPC-LCM-READ topic.

 

Unfortunately other errors appeared in the APPC logs.

 

Error 1: Error message (in the attached file) appears when a message from the topic APPC-LCM-READ has been consumed. AAI query works fine but the type of the VNF is set to vLoadBalancer_20190821/null". Could be the “/null” the cause?

Subsequently, in the same attached log, the VNF HealthCheck operation fails.

 

 

Error2: we get the error  ":"No such topic exists.-[APPC-CL]". Could you provide us with some details about such topic?

Which ONAP component writes the DMaaP topic APPC-CL ?

What are the difference of use between APPC-LCM-READ and APPC-CL  as both seem to be read by the APPC?

2019-08-28 09:47:37,750 | INFO  | Appc-Listener-2  | EventHandlerImpl                 | 426 - appc-common-bundle - 1.5.2 | Read 0 messages from APPC-CL as appcDemoEventListener/644.

2019-08-28 09:47:37,750 | INFO  | Appc-Listener-2  | EventHandlerImpl                 | 426 - appc-common-bundle - 1.5.2 | Getting up to 1000 incoming events

2019-08-28 09:47:37,751 | INFO  | Appc-Listener-2  | HttpDmaapConsumerImpl            | 426 - appc-common-bundle - 1.5.2 | GET http://message-router.onap:3904/events/APPC-CL/appcDemoEventListener/644?timeout=60000&limit=1000

2019-08-28 09:47:37,757 | ERROR | Appc-Listener-2  | HttpDmaapConsumerImpl            | 426 - appc-common-bundle - 1.5.2 | Did not get 200 from DMaaP. Got 404 - {"mrstatus":3001,"helpURL":"http://onap.readthedocs.io","message":"No such topic exists.-[APPC-CL]","status":404}

2019-08-28 09:47:37,757 | INFO  | Appc-Listener-2  | HttpDmaapConsumerImpl            | 426 - appc-common-bundle - 1.5.2 | Sleeping for 60s after failed request

 

 

Error3: It is categorized like INFO (not ERROR) but  a stack trace appears. Could be something the affect the normal APPC operation?

2019-08-28 09:46:37,749 | INFO  | Appc-Listener-2  | HttpDmaapConsumerImpl            | 426 - appc-common-bundle - 1.5.2 | Sleeping for 60s after failed request

2019-08-28 09:46:53,498 | INFO  | Appc-Listener-1  | HttpDmaapConsumerImpl            | 426 - appc-common-bundle - 1.5.2 | Got 0 messages from DMaaP

2019-08-28 09:46:53,498 | INFO  | Appc-Listener-1  | EventHandlerImpl                 | 426 - appc-common-bundle - 1.5.2 | Read 0 messages from APPC-LCM-READ as APPC-EVENT-LISTENER-TEST/74.

2019-08-28 09:46:53,499 | INFO  | Appc-Listener-1  | EventHandlerImpl                 | 426 - appc-common-bundle - 1.5.2 | Getting up to 10 incoming events

2019-08-28 09:46:53,499 | INFO  | Appc-Listener-1  | HttpDmaapConsumerImpl            | 426 - appc-common-bundle - 1.5.2 | GET http://message-router.onap:3904/events/APPC-LCM-READ/APPC-EVENT-LISTENER-TEST/74?timeout=60000&limit=10

2019-08-28 09:47:34,971 | INFO  | s4j.pax.logging) | fileinstall                      | 7 - org.apache.felix.fileinstall - 3.6.4 | Unable to save configuration

java.io.FileNotFoundException: /opt/opendaylight/etc/org.ops4j.pax.logging.cfg (Read-only file system)

        at java.io.FileOutputStream.open0(Native Method) ~[?:?]

        at java.io.FileOutputStream.open(FileOutputStream.java:270) [?:?]

        at java.io.FileOutputStream.<init>(FileOutputStream.java:213) [?:?]

        at java.io.FileOutputStream.<init>(FileOutputStream.java:162) [?:?]

        at org.apache.felix.fileinstall.internal.ConfigInstaller.doConfigurationEvent(ConfigInstaller.java:186) [7:org.apache.felix.fileinstall:3.6.4]

        at org.apache.felix.fileinstall.internal.ConfigInstaller.configurationEvent(ConfigInstaller.java:129) [7:org.apache.felix.fileinstall:3.6.4]

        at org.apache.felix.cm.impl.ConfigurationManager$FireConfigurationEvent.sendEvent(ConfigurationManager.java:2090) [6:org.apache.felix.configadmin:1.8.16]

        at org.apache.felix.cm.impl.ConfigurationManager$FireConfigurationEvent.run(ConfigurationManager.java:2058) [6:org.apache.felix.configadmin:1.8.16]

        at org.apache.felix.cm.impl.UpdateThread.run0(UpdateThread.java:141) [6:org.apache.felix.configadmin:1.8.16]

        at org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:109) [6:org.apache.felix.configadmin:1.8.16]

        at java.lang.Thread.run(Thread.java:748) [?:?]

 

 

Error 4: this error highlights the lack of file blueprints-processor-adaptor.properties.

Once this error appears, APPC processing exits waiting for next request. Could be due to something that went wrong in the distribution or instantiation phase?

Could it be a bug of APPC release we are using i.e. Image: nexus3.onap.org:10001/onap/appc-image:1.5.3 ?

2019-08-28 09:47:53,601 | INFO  | Appc-Listener-1  | HttpDmaapConsumerImpl            | 426 - appc-common-bundle - 1.5.2 | Got 0 messages from DMaaP

2019-08-28 09:47:53,602 | INFO  | Appc-Listener-1  | EventHandlerImpl                 | 426 - appc-common-bundle - 1.5.2 | Read 0 messages from APPC-LCM-READ as APPC-EVENT-LISTENER-TEST/74.

2019-08-28 09:47:53,603 | INFO  | Appc-Listener-1  | EventHandlerImpl                 | 426 - appc-common-bundle - 1.5.2 | Getting up to 10 incoming events

2019-08-28 09:47:53,604 | INFO  | Appc-Listener-1  | HttpDmaapConsumerImpl            | 426 - appc-common-bundle - 1.5.2 | GET http://message-router.onap:3904/events/APPC-LCM-READ/APPC-EVENT-LISTENER-TEST/74?timeout=60000&limit=10

2019-08-28 09:48:05,969 | ERROR | pool-30-thread-1 | ConfigRestAdaptorServiceImpl     | 358 - wrap_file__opt_opendaylight_system_com_att_eelf_eelf-core_1.0.0_eelf-core-1.0.0.jar - 0.0.0 | Failed to load properties for file: {} blueprints-processor-adaptor.properties

java.io.FileNotFoundException: /blueprints-processor-adaptor.properties (No such file or directory)

        at java.io.FileInputStream.open0(Native Method) ~[?:?]

        at java.io.FileInputStream.open(FileInputStream.java:195) ~[?:?]

        at java.io.FileInputStream.<init>(FileInputStream.java:138) ~[?:?]

        at java.io.FileInputStream.<init>(FileInputStream.java:93) ~[?:?]

        at org.onap.ccsdk.features.rest.adaptor.service.ConfigRestAdaptorServiceImpl.doLoadFromPath(ConfigRestAdaptorServiceImpl.java:99) ~[?:?]

        at org.onap.ccsdk.features.rest.adaptor.service.ConfigRestAdaptorServiceImpl.loadProps(ConfigRestAdaptorServiceImpl.java:91) ~[?:?]

        at org.onap.ccsdk.features.rest.adaptor.service.ConfigRestAdaptorServiceImpl.lambda$new$0(ConfigRestAdaptorServiceImpl.java:60) ~[?:?]

        at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [?:?]

        at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308) [?:?]

        at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180) [?:?]

        at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294) [?:?]

        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:?]

        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:?]

        at java.lang.Thread.run(Thread.java:748) [?:?]

 

 

 

Thank you for the help.

Marco Ferrero

Alessandro D’Alessandro.

 

 

From: PLATANIA, MARCO (MARCO) [mailto:platania@...]

Sent: giovedì 22 agosto 2019 19:00
To: D'Alessandro Alessandro Gerardo <alessandro.dalessandro@...>; VENKATESH KUMAR, VIJAY <vv770d@...>; onap-discuss@...
Cc: MALAKOV, YURIY <ym9479@...>; Malinconico Aniello Paolo <a.malinconico@...>; Ferrero Marco Angelo <marco.ferrero@...>
Subject: [EXT] Re: vDNS use case / issue with SO pub about APPC-READ

 

Messages published in APPC-LCM-WRITE definitely come from APPC (unless you set the topics differently, which is not the common case). APPC reads from APP-LCM-READ (which is where clients like SO publish). Being APPC-LCM-WRITE a shared channel between APPC and possibly multiple clients, the originator ID is just to express which client sent the input message (in APP-LCM-READ). I believe this is why you see MSO as originator ID.

 

Regarding the actual error, I think your K8S cluster has some nodes out of sync. Try to see if the timestamps in the VMs (or physical hosts) are synchronized. I’m quite sure that’s not an ONAP-related issue.

 

Marco

 

From: D'Alessandro Alessandro Gerardo <alessandro.dalessandro@...>
Date: Thursday, August 22, 2019 at 11:42 AM
To: "PLATANIA, MARCO (MARCO)" <
platania@...>, "VENKATESH KUMAR, VIJAY" <vv770d@...>, "onap-discuss@..." <onap-discuss@...>
Cc: "MALAKOV, YURIY" <
ym9479@...>, Malinconico Aniello Paolo <a.malinconico@...>, Ferrero Marco Angelo <marco.ferrero@...>
Subject: vDNS use case / issue with SO pub about APPC-READ

 

Hi All,

we are continue working on vDNS use case (https://docs.onap.org/en/latest/submodules/integration.git/docs/docs_scaleout.html ) primarily focusing on closed loop aspects



we successfully carried out the following steps related to the above guide

“PART 1 - Service Definition and Onboarding”

“PART 2 - Scale Out Use Case Instantiation”

“PART 3 - Post Instantiation Operations”

“3-1 Using the VNF : vLB Manual Configuration”… skipped because it was carried out automatically  

“3-2 Updating AAI with VNF resources”

 

After this steps we see vPKG does NOT generates packets. Anyway making that working is not our primary goal at this stage.

We changed the TCA rules as “if packets are LESS than 2000 than call policy operation” and this rules is always satisfied in our case. In fact we have seen MSO publishing a topic “APPC-LCM-READ” asking for "action":"HealthCheck". Refer to attached file “APPC_LCM_READ_messagerouter”

 

In the APP-C log you can also find “InvalidInputException : Input Timestamp is of future” associated to the messages related to the topic “APPC-LCM-READ”. Refer to attached file “appc_log_errortimestamp”

 

Afterwards we have noticed under topic “APPC-LCM-WRITE”  the following  "message":"INVALID INPUT PARAMETER - Input Timestamp is of future = Thu Aug 22 10:28:58 GMT 2019"           followed by  the          

"message":"UNEXPECTED ERROR - java.lang.IllegalStateException". Refer to attached file “APPC_LCM_WRITE_messagerouter”. Such messages are apparently published by MSO because that is the name associated to the field "originator-id" while we expected it was published by APPC as we understood from the  GET http://message-router.onap:3904/events/APPC-LCM-WRITE found in “bpmn_debug_cut.log”).

 

In the MSO log you can find the following error “Error Message: Unable to invoke action : HealthCheck”. Refer to attached file “bpmn_debug_cut.log”

 

 

Do you have any suggestion how to fix such issue?

Is there any document describing the semantic of messages published from both MSO and APPC?

 

Thanks in advance

 

Best regards,

Alessandro

 

Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie.

This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks.

Rispetta l'ambiente. Non stampare questa mail se non è necessario.

 


External Email: Please use caution when opening links and attachments / Courriel externe: Soyez prudent avec les liens et documents joints

 

 


External Email: Please use caution when opening links and attachments / Courriel externe: Soyez prudent avec les liens et documents joints


External Email: Please use caution when opening links and attachments / Courriel externe: Soyez prudent avec les liens et documents joints

Re: [EXT] Re: [onap-discuss] vDNS use case / issue with SO pub about APPC-READ

Marco Platania
 

I don’t think the error is in SO, it’s SDNC/CDS. SO reports this:

 

Exception in org.onap.so.bpmn.infrastructure.sdnc.tasks.SDNCAssignTasks.assignVfModule VF Module model info is null for 37c24a9f-27b2-46cb-b94a-1df0372d1a6f

 

The SO issue happens in the UnassignBB, which runs after the assign failed, so your problem is different than the one reported by the exception in the logs. Please reach out to CDS Team to understand if your setting/configuration is correct.

 

Note that vLB/vDNS/vPKG need Ubuntu 1604, not 1404. This is why your VNFs aren’t coming up clean.

 

Marco

 

From: "Mir, Adil Kamal" <adil_kamal.mir@...>
Date: Thursday, August 29, 2019 at 11:58 AM
To: Ferrero Marco Angelo <marco.ferrero@...>, "onap-discuss@..." <onap-discuss@...>, "PLATANIA, MARCO (MARCO)" <platania@...>, D'Alessandro Alessandro Gerardo <alessandro.dalessandro@...>, "VENKATESH KUMAR, VIJAY" <vv770d@...>
Cc: "MALAKOV, YURIY" <ym9479@...>, Malinconico Aniello Paolo <a.malinconico@...>, "CHO, TAKAMUNE" <tc012c@...>
Subject: RE: R: [EXT] Re: [onap-discuss] vDNS use case / issue with SO pub about APPC-READ

 

Hi Marco,

 

Yes seems like the vf-module being created in AAI is lacking the required model info, this is what I have in AAI:

 

https://{{host}}:30233/aai/v15/network/generic-vnfs/generic-vnf/0d57e81c-53cf-40a0-8cc1-ae2a255ae473/vf-modules

{

    "vf-module": [

        {

            "vf-module-id": "54c15368-108d-4350-9fc3-bee00bb2e17b",

            "vf-module-name": "RegionOne_ONAP-NF_20190827T172215759Z_vlb_Expansion_001",

            "heat-stack-id": "RegionOne_ONAP-NF_20190827T172215759Z_vlb_Expansion_001/681ee7c5-3906-434f-9722-12f6086dfe81",

           "orchestration-status": "Active",

            "is-base-vf-module": false,

            "automated-assignment": false,

            "resource-version": "1566927307195",

            "model-invariant-id": "cbdcabc4-18bf-4b12-a1cf-5483baad1563",

            "model-version-id": "bfda7ba8-4a30-4689-b662-1dc3c5abfe3d",

            "model-customization-id": "291d82cf-c5e4-418f-bbcf-371c65f9d2dd",

            "module-index": 0,

            "selflink": "restconf/config/GENERIC-RESOURCE-API:services/service/bcbaba23-249a-4a05-835b-8a9e2167f344/service-data/vnfs/vnf/0d57e81c-53cf-40a0-8cc1-ae2a255ae473/vnf-data/vf-modules/vf-module/54c15368-108d-4350-9fc3-bee00bb2e17b/vf-module-data/vf-module-topology/",

            "relationship-list": {

                "relationship": [

                    {

                        "related-to": "vserver",

                        "relationship-label": "org.onap.relationships.inventory.Uses",

                        "related-link": "/aai/v15/cloud-infrastructure/cloud-regions/cloud-region/CloudOwner/RegionOne/tenants/tenant/7320ec4a5b9d4589ba7c4412ccfd290f/vservers/vserver/725c37e0-5db2-4238-b06a-ef363bfb2840",

                        "relationship-data": [

                            {

                                "relationship-key": "cloud-region.cloud-owner",

                                "relationship-value": "CloudOwner"

                            },

                            {

                                "relationship-key": "cloud-region.cloud-region-id",

                                "relationship-value": "RegionOne"

                            },

                            {

                                "relationship-key": "tenant.tenant-id",

                                "relationship-value": "7320ec4a5b9d4589ba7c4412ccfd290f"

                            },

                            {

                                "relationship-key": "vserver.vserver-id",

                                "relationship-value": "725c37e0-5db2-4238-b06a-ef363bfb2840"

                            }

                        ],

                        "related-to-property": [

                            {

                                "property-key": "vserver.vserver-name",

                                "property-value": "RegionOne_ONAP-NF_20190827T172215759Z_vlb_001"

                            }

                        ]

                    }

                ]

            }

        },

        {

            "vf-module-id": "8835b9a0-38ce-4bce-abc8-8c98c2247c01",

            "vf-module-name": "RegionOne_ONAP-NF_20190827T172215759Z_base_template_Base_001",

            "heat-stack-id": "RegionOne_ONAP-NF_20190827T172215759Z_base_template_Base_001/991b2f7e-5686-4cb8-ae7f-d5147457e424",

            "orchestration-status": "Active",

            "is-base-vf-module": true,

            "automated-assignment": false,

            "resource-version": "1566926952182",

            "model-invariant-id": "d7b402b0-c30d-4b50-ac6b-cac01deb2788",

            "model-version-id": "7b1d387d-d77f-4dab-be11-8529f3c79936",

            "model-customization-id": "d4a8d05f-c477-40ab-b166-cfb1bf1b13f5",

            "module-index": 0,

            "selflink": "restconf/config/GENERIC-RESOURCE-API:services/service/bcbaba23-249a-4a05-835b-8a9e2167f344/service-data/vnfs/vnf/0d57e81c-53cf-40a0-8cc1-ae2a255ae473/vnf-data/vf-modules/vf-module/8835b9a0-38ce-4bce-abc8-8c98c2247c01/vf-module-data/vf-module-topology/"

        },

        {

            "vf-module-id": "94e2e415-c4a2-4a84-b252-3dd368c99829",

            "vf-module-name": "RegionOne_ONAP-NF_20190827T172215759Z_vdns_Expansion_001",

            "heat-stack-id": "RegionOne_ONAP-NF_20190827T172215759Z_vdns_Expansion_001/3a828c5b-b9d7-4dee-971d-9e1c7a6b36ef",

            "orchestration-status": "Active",

            "is-base-vf-module": false,

            "automated-assignment": false,

            "resource-version": "1566927326724",

            "model-invariant-id": "d90cc7c9-39a0-49b7-b8c5-4e65a168138d",

            "model-version-id": "296c94c5-8d6b-47a9-b571-ae5a28711508",

            "model-customization-id": "afb0c617-52cf-4d31-9362-8d1c60ab2729",

            "module-index": 0,

            "selflink": "restconf/config/GENERIC-RESOURCE-API:services/service/bcbaba23-249a-4a05-835b-8a9e2167f344/service-data/vnfs/vnf/0d57e81c-53cf-40a0-8cc1-ae2a255ae473/vnf-data/vf-modules/vf-module/94e2e415-c4a2-4a84-b252-3dd368c99829/vf-module-data/vf-module-topology/"

        },

        {

            "vf-module-id": "4b965f71-4d32-4c4f-9677-b01e42365865",

            "vf-module-name": "vfModuleName",

            "orchestration-status": "Inventoried",

            "is-base-vf-module": false,

            "automated-assignment": false,

            "resource-version": "1567092785202",

            "module-index": 0

        },

        {

            "vf-module-id": "4576013f-e4eb-4264-b557-5a475bdfaca4",

            "vf-module-name": "RegionOne_ONAP-NF_20190827T172215759Z_vpkg_Expansion_001",

            "heat-stack-id": "RegionOne_ONAP-NF_20190827T172215759Z_vpkg_Expansion_001/bb304b12-a01a-4e4f-8479-268e9a4ac8b5",

            "orchestration-status": "Active",

            "is-base-vf-module": false,

            "automated-assignment": false,

            "resource-version": "1566926970260",

            "model-invariant-id": "89d46387-a8aa-4ce3-ab81-bfcd0905c586",

            "model-version-id": "1c41be0c-c3ba-42d4-a922-797cc75fad46",

            "model-customization-id": "1cc381ed-c0a9-4d58-ab9f-a4cfc9ba6634",

            "module-index": 0,

            "selflink": "restconf/config/GENERIC-RESOURCE-API:services/service/bcbaba23-249a-4a05-835b-8a9e2167f344/service-data/vnfs/vnf/0d57e81c-53cf-40a0-8cc1-ae2a255ae473/vnf-data/vf-modules/vf-module/4576013f-e4eb-4264-b557-5a475bdfaca4/vf-module-data/vf-module-topology/"

        }

    ]

}

 

From a test class that I saw over here (https://github.com/onap/so/blob/master/bpmn/so-bpmn-tasks/src/test/java/org/onap/so/client/sdnc/mapper/VfModuleTopologyOperationRequestMapperTest.java

) I think its missing the vfModuleModelInvariantUuid, vfModuleModelName, vfModuleModelVersion, vfModuleModelUuid, vfModuleModelCustomizationUuid… but not sure why are these missing in the PUT request to AAI to begin with.

 

I have also attached the SO request which does have that model info.

 

For the rest of your questions,

 

Please, could you log into the vm that runs the vPKG  and send us

  • output of the ifconfig command
  • ubuntu@regionone-onap-nf-20190827t172215759z-vpg-001:~$ ifconfig
  • br0       Link encap:Ethernet  HWaddr fa:16:3e:00:00:20  
  •           inet addr:192.168.20.56  Bcast:192.168.20.255  Mask:255.255.255.0
  •           inet6 addr: fe80::2da:e7ff:fe12:729c/64 Scope:Link
  •           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
  •           RX packets:50569 errors:0 dropped:0 overruns:0 frame:0
  •           TX packets:1107 errors:0 dropped:0 overruns:0 carrier:0
  •           collisions:0 txqueuelen:1000 
  •           RX bytes:5761194 (5.7 MB)  TX bytes:167400 (167.4 KB)
  •  
  • eth0      Link encap:Ethernet  HWaddr fa:16:3e:e2:8d:42  
  •           inet addr:10.195.197.12  Bcast:10.195.197.255  Mask:255.255.255.0
  •           inet6 addr: fe80::f816:3eff:fee2:8d42/64 Scope:Link
  •           UP BROADCAST RUNNING MULTICAST  MTU:9000  Metric:1
  •           RX packets:58053 errors:0 dropped:4 overruns:0 frame:0
  •           TX packets:1172 errors:0 dropped:0 overruns:0 carrier:0
  •           collisions:0 txqueuelen:1000 
  •           RX bytes:7466836 (7.4 MB)  TX bytes:142087 (142.0 KB)
  •  
  • eth1      Link encap:Ethernet  HWaddr 00:da:e7:12:72:9c  
  •           inet6 addr: fe80::2da:e7ff:fe12:729c/64 Scope:Link
  •           UP BROADCAST RUNNING MULTICAST  MTU:9000  Metric:1
  •           RX packets:50574 errors:0 dropped:0 overruns:0 frame:0
  •           TX packets:58845 errors:0 dropped:0 overruns:0 carrier:0
  •           collisions:0 txqueuelen:1000 
  •           RX bytes:6469578 (6.4 MB)  TX bytes:6749092 (6.7 MB)
  •  
  • eth2      Link encap:Ethernet  HWaddr fa:16:3e:ff:f8:66  
  •           inet addr:10.0.101.39  Bcast:10.0.255.255  Mask:255.255.0.0
  •           inet6 addr: fe80::f816:3eff:feff:f866/64 Scope:Link
  •           UP BROADCAST RUNNING MULTICAST  MTU:9000  Metric:1
  •           RX packets:16 errors:0 dropped:0 overruns:0 frame:0
  •           TX packets:7 errors:0 dropped:0 overruns:0 carrier:0
  •           collisions:0 txqueuelen:1000 
  •           RX bytes:1296 (1.2 KB)  TX bytes:578 (578.0 B)
  •  
  • lo        Link encap:Local Loopback  
  •           inet addr:127.0.0.1  Mask:255.0.0.0
  •           inet6 addr: ::1/128 Scope:Host
  •           UP LOOPBACK RUNNING  MTU:65536  Metric:1
  •           RX packets:160 errors:0 dropped:0 overruns:0 frame:0
  •           TX packets:160 errors:0 dropped:0 overruns:0 carrier:0
  •           collisions:0 txqueuelen:1 
  •           RX bytes:11840 (11.8 KB)  TX bytes:11840 (11.8 KB)
  •  
  • tap111    Link encap:Ethernet  HWaddr 6e:63:3a:6c:9d:6f  
  •           inet6 addr: fe80::6c63:3aff:fe6c:9d6f/64 Scope:Link
  •           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
  •           RX packets:57725 errors:0 dropped:0 overruns:0 frame:0
  •           TX packets:23 errors:0 dropped:0 overruns:0 carrier:0
  •           collisions:0 txqueuelen:1000 
  •           RX bytes:6580650 (6.5 MB)  TX bytes:1798 (1.7 KB)

 

  • content of the file /etc/lsb-release
  • ubuntu@regionone-onap-nf-20190827t172215759z-vpg-001:~$ cat /etc/lsb-release
  • DISTRIB_ID=Ubuntu
  • DISTRIB_RELEASE=16.04
  • DISTRIB_CODENAME=xenial
  • DISTRIB_DESCRIPTION="Ubuntu 16.04.3 LTS"

 

 

I noticed that the vLB in particular was not coming up fine (some packages were not installed) when using Ubuntu 14.04. Also note that 10.195.197.12 is from our openstack public network and 10.0.101.39 from our OAM network that can reach the ONAP k8s hosts.

 

Thank you,

Adil Mir

 

From: Ferrero Marco Angelo <marco.ferrero@...>
Date: Thursday, August 29, 2019 at 11:05 AM
To: "onap-discuss@..." <onap-discuss@...>, "Mir, Adil Kamal" <adil_kamal.mir@...>, "platania@..." <platania@...>, D'Alessandro Alessandro Gerardo <alessandro.dalessandro@...>, "VENKATESH KUMAR, VIJAY" <vv770d@...>
Cc: "MALAKOV, YURIY" <ym9479@...>, Malinconico Aniello Paolo <a.malinconico@...>, "CHO, TAKAMUNE" <tc012c@...>
Subject: [EXT]R: [EXT] Re: [onap-discuss] vDNS use case / issue with SO pub about APPC-READ

 

Hi Mir,

 

reading the log file you have sent to us I suppose the error you sent to us is due to something missing in the AAI description of the VNF.

Observing the bpmn log the request API is:

 

2019-08-28T20:50:02.778Z|| o.o.so.logging.jaxrs.filter.PayloadLoggingFilter - Making PUT request to: https://aai.onap:8443/aai/v15/network/generic-vnfs/generic-vnf/0d57e81c-53cf-40a0-8cc1-ae2a255ae473/vf-modules/vf-module/37c24a9f-27b2-46cb-b94a-1df0372d1a6f

Request Headers: {Authorization=[Basic YWFpQGFhaS5vbmFwLm9yZzpkZW1vMTIzNDU2IQ==], X-FromAppId=[MSO], X-TransactionId=[], Accept=[application/json], Content-Type=[application/json], X-ONAP-RequestID=[0e896d09-5b4e-4466-baab-5f1b27f89ae2], X-ONAP-InvocationID=[0c906cd3-1fe4-4241-a801-4b0a1f867ff6], X-ONAP-PartnerName=[SO]}

 

This seem to be the body of the request

 

2019-08-28T20:50:02.779Z|| o.o.so.logging.jaxrs.filter.PayloadLoggingFilter - {"vf-module-id":"37c24a9f-27b2-46cb-b94a-1df0372d1a6f","vf-module-name":"vDNS-VM-02","orchestration-status":"Inventoried","module-index":0}

 

Seem a SO request done to the AAI.

 

Unfortunately the sent back by the AAI breaks the code of the sdnc client of the AAI

 

2019-08-28T20:50:03.149Z|| o.o.s.bpmn.infrastructure.aai.tasks.AAICreateTasks - VolumeGroup not found. Skipping Connect between VfModule and VolumeGroup

2019-08-28T20:50:03.149Z|| o.o.s.b.infrastructure.sdnc.tasks.SDNCAssignTasks - No volume group was found.

2019-08-28T20:50:03.151Z|| org.onap.so.client.exception.ExceptionBuilder - Exception occurred

org.onap.so.client.exception.MapperException: VF Module model info is null for 37c24a9f-27b2-46cb-b94a-1df0372d1a6f

         at org.onap.so.client.sdnc.mapper.GeneralTopologyObjectMapper.buildVfModuleInformation(GeneralTopologyObjectMapper.java:163)

         at org.onap.so.client.sdnc.mapper.VfModuleTopologyOperationRequestMapper.reqMapper(VfModuleTopologyOperationRequestMapper.java:112)

 

Please, can you query the AAI and send us its response ?

 

I tried to find the classes that appear in the stack trace by looking here

https://gerrit.onap.org/r/gitweb?p=so.git;a=tree;h=refs/heads/dublin;hb=refs/heads/dublin

but I was not able to find them.

Someone knows where are located these classes ?

 

In our case the packet generator doesn’t sends DNS queries once the service was instantiated so in order to test the closed-loop chain we negated the check condition. In other words we changed

receivedPacketsDelta GREATER_OR_EQUAL

to

receivedPacketDelta LESS

 

we still problems but we discovered in our installation that the sdnctl database has been created but a lot of tables were not populated. We hope to solve the problem once these tables will be correctly populated.

 

Now we analyze the packed generator in order to check of differences between our and your installation.

Last week we already noticed problems that are described in the mail attached to this message.

 

Please, could you log into the vm that runs the vPKG  and send us

  • output of the ifconfig command
  • content of the file /etc/lsb-release

 

Thank you for your help.

Best regards

 

Marco Ferrero

Alessandro D’Alessandro

 

 

------------------------------------------------------------------
TIM

Marco Angelo Ferrero
Mobile & Fixed Innovation
IP, Transport & Core Innovation

TIM S.p.A.
Via G. Reiss Romoli, 274 – 10148 TORINO
+39 011 2286739
+39 331 6001354

 

Da: onap-discuss@... [mailto:onap-discuss@...] Per conto di Mir, Adil Kamal
Inviato: mercoledì 28 agosto 2019 23:07
A: onap-discuss@...; platania@...; D'Alessandro Alessandro Gerardo; VENKATESH KUMAR, VIJAY
Cc: MALAKOV, YURIY; Malinconico Aniello Paolo; Ferrero Marco Angelo; CHO, TAKAMUNE
Oggetto: [EXT] Re: [onap-discuss] vDNS use case / issue with SO pub about APPC-READ

 

Hello Alessandro and Marco,

 

I hope you can help me with vDNS use case as well. I was able to go a bit further and have the following:

 

The packet generator is sending DNS queries as expected, and the threshold does get violated on TCA which fires an event of DCAE-CL, and therefore ending up with a SO action for scale out.

 

However, the SO request after successfully doing the vLB health check via APPC fails with the following status message:

        "requestStatus": {

            "requestState": "FAILED",

            "statusMessage": "STATUS: Exception in org.onap.so.bpmn.infrastructure.sdnc.tasks.SDNCAssignTasks.assignVfModule VF Module model info is null for 37c24a9f-27b2-46cb-b94a-1df0372d1a6f FLOW STATUS: UnassignVfModuleBB has failed. ROLLBACK STATUS: Failed to determine rollback error message.",

            "percentProgress": 100,

            "timestamp": "Wed, 28 Aug 2019 20:50:16 GMT"

        }

 

In SO logs I can see the following exception:

 

2019-08-28T20:50:02.779Z|| o.o.so.logging.jaxrs.filter.PayloadLoggingFilter - {"vf-module-id":"37c24a9f-27b2-46cb-b94a-1df0372d1a6f","vf-module-name":"vDNS-VM-02","orchestration-status":"Inventoried","module-index":0}

 

2019-08-28T20:50:03.149Z|| o.o.s.bpmn.infrastructure.aai.tasks.AAICreateTasks - VolumeGroup not found. Skipping Connect between VfModule and VolumeGroup

2019-08-28T20:50:03.149Z|| o.o.s.b.infrastructure.sdnc.tasks.SDNCAssignTasks - No volume group was found.

2019-08-28T20:50:03.151Z|| org.onap.so.client.exception.ExceptionBuilder - Exception occurred

org.onap.so.client.exception.MapperException: VF Module model info is null for 37c24a9f-27b2-46cb-b94a-1df0372d1a6f

       at org.onap.so.client.sdnc.mapper.GeneralTopologyObjectMapper.buildVfModuleInformation(GeneralTopologyObjectMapper.java:163)

       at org.onap.so.client.sdnc.mapper.VfModuleTopologyOperationRequestMapper.reqMapper(VfModuleTopologyOperationRequestMapper.java:112)

       at org.onap.so.client.orchestration.SDNCVfModuleResources.assignVfModule(SDNCVfModuleResources.java:57)

       at org.onap.so.bpmn.infrastructure.sdnc.tasks.SDNCAssignTasks.assignVfModule(SDNCAssignTasks.java:124)

       at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

       at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)

       at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

       at java.lang.reflect.Method.invoke(Method.java:498)

 

I am also attaching the full SO BPMN logs for your reference.

 

Any idea what am I missing?

 

Thanks,

Adil

 

From: <onap-discuss@...> on behalf of Marco Platania <platania@...>
Reply-To: "onap-discuss@..." <onap-discuss@...>, "platania@..." <platania@...>
Date: Wednesday, August 28, 2019 at 2:01 PM
To: D'Alessandro Alessandro Gerardo <alessandro.dalessandro@...>, "VENKATESH KUMAR, VIJAY" <vv770d@...>, "onap-discuss@..." <onap-discuss@...>
Cc: "MALAKOV, YURIY" <ym9479@...>, Malinconico Aniello Paolo <a.malinconico@...>, Ferrero Marco Angelo <marco.ferrero@...>, "CHO, TAKAMUNE" <tc012c@...>
Subject: [EXT]Re: [onap-discuss] vDNS use case / issue with SO pub about APPC-READ

 

Error 1 may be a symptom that the APPC DB hasn’t been populated correctly when it was installed. Connect to the sdnctl DB (user sdnctl, pwd gamma) and see if the VNF_TO_DG_MAPPING table has entries. If not, something went wrong during the DB installation. You may try to fix it by inserting the VNF to DG mappings manually (see SQL code below), but there’s a chance that other tables haven’t been populated as well, so you may have more problems later on.

 

insert into VNF_DG_MAPPING (VNF_DG_MAPPING_ID, ACTION, API_VERSION, VNF_TYPE, VNF_VERSION, DG_NAME, DG_VERSION, DG_MODULE) values

(1, 'Restart', '2.00', '', '', 'Generic_Restart', '3.0.0', 'APPC'),

(2, 'Configure', NULL, NULL, NULL, 'DGOrchestrator', '4.0.0', 'APPC'),

(3, 'ConfigModify', NULL, NULL, NULL, 'DGOrchestrator', '4.0.0', 'APPC'),

(4, 'Rebuild', NULL, NULL, NULL, 'DGOrchestrator', '4.0.0', 'APPC'),

(5, 'Restart', NULL, NULL, NULL, 'DGOrchestrator', '4.0.0', 'APPC'),

(6, 'HealthCheck', NULL, NULL, NULL, 'DGOrchestrator', '4.0.0', 'APPC'),

(7, 'StartApplication', NULL, NULL, NULL, 'DGOrchestrator', '4.0.0', 'APPC'),

(8, 'StopApplication', NULL, NULL, NULL, 'DGOrchestrator', '4.0.0', 'APPC'),

(9, 'Migrate', NULL, NULL, NULL, 'DGOrchestrator', '4.0.0', 'APPC'),

(10, 'Snapshot', NULL, NULL, NULL, 'DGOrchestrator', '4.0.0', 'APPC'),

(11, 'ConfigRestore', NULL, NULL, NULL, 'DGOrchestrator', '4.0.0', 'APPC'),

(12, 'ConfigBackup', NULL, NULL, NULL, 'DGOrchestrator', '4.0.0', 'APPC'),

(13, 'Evacuate', NULL, NULL, NULL, 'DGOrchestrator', '4.0.0', 'APPC'),

(14, 'Stop', NULL, NULL, NULL, 'DGOrchestrator', '4.0.0', 'APPC'),

(15, 'Start', NULL, NULL, NULL, 'DGOrchestrator', '4.0.0', 'APPC'),

(16, 'ConfigScaleOut', NULL, NULL, NULL, 'DGOrchestrator', '4.0.0', 'APPC'),

(17, 'DistributeTraffic', NULL, NULL, NULL, 'DGOrchestrator', '4.0.0', 'APPC'),

(18, 'DistributeTrafficCheck', NULL, NULL, NULL, 'DGOrchestrator', '4.0.0', 'APPC');

 

Error 2 is not a real issue, that topic isn’t used in ONAP. Error 4 is innocuous as well, please disregard it.

 

Error 3 I don’t know honestly, it seems a logging/permission issue. Not sure how bad it is, but I wouldn’t be surprised if it’s another symptom that something went wrong during APPC instantiation.

 

 

Taka,

 

Can you please add more on this? For what regards error 1, is it possible to re-run only the job that populates the DB, or should one rebuild APPC from scratch?

 

Thanks,

Marco

 

 

 

From: D'Alessandro Alessandro Gerardo <alessandro.dalessandro@...>
Date: Wednesday, August 28, 2019 at 12:32 PM
To: "PLATANIA, MARCO (MARCO)" <platania@...>, "VENKATESH KUMAR, VIJAY" <vv770d@...>, "onap-discuss@..." <onap-discuss@...>
Cc: "MALAKOV, YURIY" <ym9479@...>, Malinconico Aniello Paolo <a.malinconico@...>, Ferrero Marco Angelo <marco.ferrero@...>
Subject: RE: vDNS use case / issue with SO pub about APPC-READ

 

Hi Marco,

Error about “future timestamp” in the APPC log has been fixed synchronizing all k8s VMs. Thanks.

ONAP was able to read data from APPC-LCM-READ topic.

 

Unfortunately other errors appeared in the APPC logs.

 

Error 1: Error message (in the attached file) appears when a message from the topic APPC-LCM-READ has been consumed. AAI query works fine but the type of the VNF is set to vLoadBalancer_20190821/null". Could be the “/null” the cause?

Subsequently, in the same attached log, the VNF HealthCheck operation fails.

 

 

Error2: we get the error  ":"No such topic exists.-[APPC-CL]". Could you provide us with some details about such topic?

Which ONAP component writes the DMaaP topic APPC-CL ?

What are the difference of use between APPC-LCM-READ and APPC-CL  as both seem to be read by the APPC?

2019-08-28 09:47:37,750 | INFO  | Appc-Listener-2  | EventHandlerImpl                 | 426 - appc-common-bundle - 1.5.2 | Read 0 messages from APPC-CL as appcDemoEventListener/644.

2019-08-28 09:47:37,750 | INFO  | Appc-Listener-2  | EventHandlerImpl                 | 426 - appc-common-bundle - 1.5.2 | Getting up to 1000 incoming events

2019-08-28 09:47:37,751 | INFO  | Appc-Listener-2  | HttpDmaapConsumerImpl            | 426 - appc-common-bundle - 1.5.2 | GET http://message-router.onap:3904/events/APPC-CL/appcDemoEventListener/644?timeout=60000&limit=1000

2019-08-28 09:47:37,757 | ERROR | Appc-Listener-2  | HttpDmaapConsumerImpl            | 426 - appc-common-bundle - 1.5.2 | Did not get 200 from DMaaP. Got 404 - {"mrstatus":3001,"helpURL":"http://onap.readthedocs.io","message":"No such topic exists.-[APPC-CL]","status":404}

2019-08-28 09:47:37,757 | INFO  | Appc-Listener-2  | HttpDmaapConsumerImpl            | 426 - appc-common-bundle - 1.5.2 | Sleeping for 60s after failed request

 

 

Error3: It is categorized like INFO (not ERROR) but  a stack trace appears. Could be something the affect the normal APPC operation?

2019-08-28 09:46:37,749 | INFO  | Appc-Listener-2  | HttpDmaapConsumerImpl            | 426 - appc-common-bundle - 1.5.2 | Sleeping for 60s after failed request

2019-08-28 09:46:53,498 | INFO  | Appc-Listener-1  | HttpDmaapConsumerImpl            | 426 - appc-common-bundle - 1.5.2 | Got 0 messages from DMaaP

2019-08-28 09:46:53,498 | INFO  | Appc-Listener-1  | EventHandlerImpl                 | 426 - appc-common-bundle - 1.5.2 | Read 0 messages from APPC-LCM-READ as APPC-EVENT-LISTENER-TEST/74.

2019-08-28 09:46:53,499 | INFO  | Appc-Listener-1  | EventHandlerImpl                 | 426 - appc-common-bundle - 1.5.2 | Getting up to 10 incoming events

2019-08-28 09:46:53,499 | INFO  | Appc-Listener-1  | HttpDmaapConsumerImpl            | 426 - appc-common-bundle - 1.5.2 | GET http://message-router.onap:3904/events/APPC-LCM-READ/APPC-EVENT-LISTENER-TEST/74?timeout=60000&limit=10

2019-08-28 09:47:34,971 | INFO  | s4j.pax.logging) | fileinstall                      | 7 - org.apache.felix.fileinstall - 3.6.4 | Unable to save configuration

java.io.FileNotFoundException: /opt/opendaylight/etc/org.ops4j.pax.logging.cfg (Read-only file system)

        at java.io.FileOutputStream.open0(Native Method) ~[?:?]

        at java.io.FileOutputStream.open(FileOutputStream.java:270) [?:?]

        at java.io.FileOutputStream.<init>(FileOutputStream.java:213) [?:?]

        at java.io.FileOutputStream.<init>(FileOutputStream.java:162) [?:?]

        at org.apache.felix.fileinstall.internal.ConfigInstaller.doConfigurationEvent(ConfigInstaller.java:186) [7:org.apache.felix.fileinstall:3.6.4]

        at org.apache.felix.fileinstall.internal.ConfigInstaller.configurationEvent(ConfigInstaller.java:129) [7:org.apache.felix.fileinstall:3.6.4]

        at org.apache.felix.cm.impl.ConfigurationManager$FireConfigurationEvent.sendEvent(ConfigurationManager.java:2090) [6:org.apache.felix.configadmin:1.8.16]

        at org.apache.felix.cm.impl.ConfigurationManager$FireConfigurationEvent.run(ConfigurationManager.java:2058) [6:org.apache.felix.configadmin:1.8.16]

        at org.apache.felix.cm.impl.UpdateThread.run0(UpdateThread.java:141) [6:org.apache.felix.configadmin:1.8.16]

        at org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:109) [6:org.apache.felix.configadmin:1.8.16]

        at java.lang.Thread.run(Thread.java:748) [?:?]

 

 

Error 4: this error highlights the lack of file blueprints-processor-adaptor.properties.

Once this error appears, APPC processing exits waiting for next request. Could be due to something that went wrong in the distribution or instantiation phase?

Could it be a bug of APPC release we are using i.e. Image: nexus3.onap.org:10001/onap/appc-image:1.5.3 ?

2019-08-28 09:47:53,601 | INFO  | Appc-Listener-1  | HttpDmaapConsumerImpl            | 426 - appc-common-bundle - 1.5.2 | Got 0 messages from DMaaP

2019-08-28 09:47:53,602 | INFO  | Appc-Listener-1  | EventHandlerImpl                 | 426 - appc-common-bundle - 1.5.2 | Read 0 messages from APPC-LCM-READ as APPC-EVENT-LISTENER-TEST/74.

2019-08-28 09:47:53,603 | INFO  | Appc-Listener-1  | EventHandlerImpl                 | 426 - appc-common-bundle - 1.5.2 | Getting up to 10 incoming events

2019-08-28 09:47:53,604 | INFO  | Appc-Listener-1  | HttpDmaapConsumerImpl            | 426 - appc-common-bundle - 1.5.2 | GET http://message-router.onap:3904/events/APPC-LCM-READ/APPC-EVENT-LISTENER-TEST/74?timeout=60000&limit=10

2019-08-28 09:48:05,969 | ERROR | pool-30-thread-1 | ConfigRestAdaptorServiceImpl     | 358 - wrap_file__opt_opendaylight_system_com_att_eelf_eelf-core_1.0.0_eelf-core-1.0.0.jar - 0.0.0 | Failed to load properties for file: {} blueprints-processor-adaptor.properties

java.io.FileNotFoundException: /blueprints-processor-adaptor.properties (No such file or directory)

        at java.io.FileInputStream.open0(Native Method) ~[?:?]

        at java.io.FileInputStream.open(FileInputStream.java:195) ~[?:?]

        at java.io.FileInputStream.<init>(FileInputStream.java:138) ~[?:?]

        at java.io.FileInputStream.<init>(FileInputStream.java:93) ~[?:?]

        at org.onap.ccsdk.features.rest.adaptor.service.ConfigRestAdaptorServiceImpl.doLoadFromPath(ConfigRestAdaptorServiceImpl.java:99) ~[?:?]

        at org.onap.ccsdk.features.rest.adaptor.service.ConfigRestAdaptorServiceImpl.loadProps(ConfigRestAdaptorServiceImpl.java:91) ~[?:?]

        at org.onap.ccsdk.features.rest.adaptor.service.ConfigRestAdaptorServiceImpl.lambda$new$0(ConfigRestAdaptorServiceImpl.java:60) ~[?:?]

        at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [?:?]

        at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308) [?:?]

        at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180) [?:?]

        at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294) [?:?]

        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:?]

        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:?]

        at java.lang.Thread.run(Thread.java:748) [?:?]

 

 

 

Thank you for the help.

Marco Ferrero

Alessandro D’Alessandro.

 

 

From: PLATANIA, MARCO (MARCO) [mailto:platania@...]
Sent: giovedì 22 agosto 2019 19:00
To: D'Alessandro Alessandro Gerardo <alessandro.dalessandro@...>; VENKATESH KUMAR, VIJAY <vv770d@...>; onap-discuss@...
Cc: MALAKOV, YURIY <ym9479@...>; Malinconico Aniello Paolo <a.malinconico@...>; Ferrero Marco Angelo <marco.ferrero@...>
Subject: [EXT] Re: vDNS use case / issue with SO pub about APPC-READ

 

Messages published in APPC-LCM-WRITE definitely come from APPC (unless you set the topics differently, which is not the common case). APPC reads from APP-LCM-READ (which is where clients like SO publish). Being APPC-LCM-WRITE a shared channel between APPC and possibly multiple clients, the originator ID is just to express which client sent the input message (in APP-LCM-READ). I believe this is why you see MSO as originator ID.

 

Regarding the actual error, I think your K8S cluster has some nodes out of sync. Try to see if the timestamps in the VMs (or physical hosts) are synchronized. I’m quite sure that’s not an ONAP-related issue.

 

Marco

 

From: D'Alessandro Alessandro Gerardo <alessandro.dalessandro@...>
Date: Thursday, August 22, 2019 at 11:42 AM
To: "PLATANIA, MARCO (MARCO)" <
platania@...>, "VENKATESH KUMAR, VIJAY" <vv770d@...>, "onap-discuss@..." <onap-discuss@...>
Cc: "MALAKOV, YURIY" <
ym9479@...>, Malinconico Aniello Paolo <a.malinconico@...>, Ferrero Marco Angelo <marco.ferrero@...>
Subject: vDNS use case / issue with SO pub about APPC-READ

 

Hi All,

we are continue working on vDNS use case (https://docs.onap.org/en/latest/submodules/integration.git/docs/docs_scaleout.html ) primarily focusing on closed loop aspects




we successfully carried out the following steps related to the above guide

“PART 1 - Service Definition and Onboarding”

“PART 2 - Scale Out Use Case Instantiation”

“PART 3 - Post Instantiation Operations”

“3-1 Using the VNF : vLB Manual Configuration”… skipped because it was carried out automatically  

“3-2 Updating AAI with VNF resources”

 

After this steps we see vPKG does NOT generates packets. Anyway making that working is not our primary goal at this stage.

We changed the TCA rules as “if packets are LESS than 2000 than call policy operation” and this rules is always satisfied in our case. In fact we have seen MSO publishing a topic “APPC-LCM-READ” asking for "action":"HealthCheck". Refer to attached file “APPC_LCM_READ_messagerouter”

 

In the APP-C log you can also find “InvalidInputException : Input Timestamp is of future” associated to the messages related to the topic “APPC-LCM-READ”. Refer to attached file “appc_log_errortimestamp”

 

Afterwards we have noticed under topic “APPC-LCM-WRITE”  the following  "message":"INVALID INPUT PARAMETER - Input Timestamp is of future = Thu Aug 22 10:28:58 GMT 2019"           followed by  the          

"message":"UNEXPECTED ERROR - java.lang.IllegalStateException". Refer to attached file “APPC_LCM_WRITE_messagerouter”. Such messages are apparently published by MSO because that is the name associated to the field "originator-id" while we expected it was published by APPC as we understood from the  GET http://message-router.onap:3904/events/APPC-LCM-WRITE found in “bpmn_debug_cut.log”).

 

In the MSO log you can find the following error “Error Message: Unable to invoke action : HealthCheck”. Refer to attached file “bpmn_debug_cut.log”

 

 

Do you have any suggestion how to fix such issue?

Is there any document describing the semantic of messages published from both MSO and APPC?

 

Thanks in advance

 

Best regards,

Alessandro

 

Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie.

This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks.

Rispetta l'ambiente. Non stampare questa mail se non è necessario.

 


External Email: Please use caution when opening links and attachments / Courriel externe: Soyez prudent avec les liens et documents joints

 


External Email: Please use caution when opening links and attachments / Courriel externe: Soyez prudent avec les liens et documents joints