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

Mir, Adil Kamal
 

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

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

Mir, Adil Kamal
 

Thanks Steve for the reply.

 

I have the following:

 

http://so-catalog-db-adapter.onap:8082/ecomp/mso/catalog/v2/serviceVnfs?serviceModelName=demoVLB

 

{

    "serviceVnfs": [

        {

            "modelInfo": {

                "modelName": "vLB_CDS",

                "modelUuid": "cbc574e9-7ce8-4193-b0ca-a253ee3dcc6e",

                "modelInvariantUuid": "47de716f-f48b-4056-a89b-f4c6977b0c12",

                "modelVersion": "4.0",

                "modelCustomizationUuid": "fb1f2891-0985-4380-b52b-c07e8c76336d",

                "modelInstanceName": "vLB_CDS 0"

            },

            "toscaNodeType": "org.openecomp.resource.vf.VlbCds",

            "nfFunction": "vlb",

            "nfType": "LOADBALANCER",

            "nfRole": "vLB",

            "nfNamingCode": "ONAP-LOADBALANCER",

            "multiStageDesign": "false",

            "resourceInput": null,

            "vfModules": [

                {

                    "modelInfo": {

                        "modelName": "VlbCds..base_template..module-0",

                        "modelUuid": "7b1d387d-d77f-4dab-be11-8529f3c79936",

                        "modelInvariantUuid": "d7b402b0-c30d-4b50-ac6b-cac01deb2788",

                        "modelVersion": "1",

                        "modelCustomizationUuid": "d4a8d05f-c477-40ab-b166-cfb1bf1b13f5"

                    },

                    "isBase": true,

                    "vfModuleLabel": "base_template",

                    "initialCount": 1,

                    "hasVolumeGroup": false

                },

                {

                    "modelInfo": {

                        "modelName": "VlbCds..vpkg..module-1",

                        "modelUuid": "1c41be0c-c3ba-42d4-a922-797cc75fad46",

                        "modelInvariantUuid": "89d46387-a8aa-4ce3-ab81-bfcd0905c586",

                        "modelVersion": "1",

                        "modelCustomizationUuid": "1cc381ed-c0a9-4d58-ab9f-a4cfc9ba6634"

                    },

                    "isBase": false,

                    "vfModuleLabel": "vpkg",

                    "initialCount": 0,

                    "hasVolumeGroup": false

                },

                {

                    "modelInfo": {

                        "modelName": "VlbCds..vlb..module-2",

                        "modelUuid": "bfda7ba8-4a30-4689-b662-1dc3c5abfe3d",

                        "modelInvariantUuid": "cbdcabc4-18bf-4b12-a1cf-5483baad1563",

                        "modelVersion": "1",

                        "modelCustomizationUuid": "291d82cf-c5e4-418f-bbcf-371c65f9d2dd"

                    },

                    "isBase": false,

                    "vfModuleLabel": "vlb",

                    "initialCount": 0,

                    "hasVolumeGroup": false

                },

                {

                    "modelInfo": {

                        "modelName": "VlbCds..vdns..module-3",

                        "modelUuid": "296c94c5-8d6b-47a9-b571-ae5a28711508",

                        "modelInvariantUuid": "d90cc7c9-39a0-49b7-b8c5-4e65a168138d",

                        "modelVersion": "1",

                        "modelCustomizationUuid": "afb0c617-52cf-4d31-9362-8d1c60ab2729"

                    },

                    "isBase": false,

                    "vfModuleLabel": "vdns",

                    "initialCount": 0,

                    "hasVolumeGroup": false

                }

            ]

        }

    ]

}

 

MariaDB [catalogdb]> select * from vf_module;

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

| MODEL_UUID                           | MODEL_INVARIANT_UUID                 | MODEL_VERSION | MODEL_NAME                      | DESCRIPTION | IS_BASE | HEAT_TEMPLATE_ARTIFACT_UUID          | VOL_HEAT_TEMPLATE_ARTIFACT_UUID | CREATION_TIMESTAMP  | VNF_RESOURCE_MODEL_UUID              |

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

| 1c41be0c-c3ba-42d4-a922-797cc75fad46 | 89d46387-a8aa-4ce3-ab81-bfcd0905c586 | 1             | VlbCds..vpkg..module-1          | NULL        |       0 | 82291ebc-7882-41f4-a8cf-2e7a81e269b8 | NULL                            | 2019-08-20 19:55:02 | cbc574e9-7ce8-4193-b0ca-a253ee3dcc6e |

| 296c94c5-8d6b-47a9-b571-ae5a28711508 | d90cc7c9-39a0-49b7-b8c5-4e65a168138d | 1             | VlbCds..vdns..module-3          | NULL        |       0 | 8d787b9f-52f0-4479-acd8-0c67c20d9afc | NULL                            | 2019-08-20 19:55:02 | cbc574e9-7ce8-4193-b0ca-a253ee3dcc6e |

| 7b1d387d-d77f-4dab-be11-8529f3c79936 | d7b402b0-c30d-4b50-ac6b-cac01deb2788 | 1             | VlbCds..base_template..module-0 | NULL        |       1 | 52455468-5342-43c3-9540-e28cfaff257d | NULL                            | 2019-08-20 19:55:01 | cbc574e9-7ce8-4193-b0ca-a253ee3dcc6e |

| bfda7ba8-4a30-4689-b662-1dc3c5abfe3d | cbdcabc4-18bf-4b12-a1cf-5483baad1563 | 1             | VlbCds..vlb..module-2           | NULL        |       0 | 3c54ea10-b13a-4231-b6dc-855941a2b413 | NULL                            | 2019-08-20 19:55:02 | cbc574e9-7ce8-4193-b0ca-a253ee3dcc6e |

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

 

I also see the vf-module being created in AAI but I guess its missing information which is causing the requests to fail:

 

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/"

        }

    ]

}

 

Also it is running the scale out recipe, are you doing a scale out here?  Does your model contain the module model info to be scaled?

Yes this is a scale out scenario, the service was created using the templates referenced over here: https://onap.readthedocs.io/en/latest/submodules/integration.git/docs/docs_scaleout.html

 

Thanks,

Adil Mir

 

 

From: "SMOKOWSKI, STEVEN" <ss835w@...>
Date: Thursday, August 29, 2019 at 7:50 AM
To: "onap-discuss@..." <onap-discuss@...>, "Mir, Adil Kamal" <adil_kamal.mir@...>, "PLATANIA, MARCO" <platania@...>, D'Alessandro Alessandro Gerardo <alessandro.dalessandro@...>, "VENKATESH KUMAR, VIJAY" <vv770d@...>
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

 

Would need to confirm the distrobution of the model.  It appears to be missing here.  Can you query catalog db via command line or the API to verify that that model uuid exists?

 

Also it is running the scale out recipe, are you doing a scale out here?  Does your model contain the module model info to be scaled?

 

Thanks

 

-Steve

 

From: <onap-discuss@...> on behalf of "Mir, Adil Kamal" <adil_kamal.mir@...>
Reply-To: "onap-discuss@..." <onap-discuss@...>, "adil_kamal.mir@..." <adil_kamal.mir@...>
Date: Wednesday, August 28, 2019 at 5:12 PM
To: "onap-discuss@..." <onap-discuss@...>, "PLATANIA, MARCO" <platania@...>, D'Alessandro Alessandro Gerardo <alessandro.dalessandro@...>, "VENKATESH KUMAR, VIJAY" <vv770d@...>
Cc: "MALAKOV, YURIY" <ym9479@...>, Malinconico Aniello Paolo <a.malinconico@...>, Ferrero Marco Angelo <marco.ferrero@...>, "CHO, TAKAMUNE" <tc012c@...>
Subject: 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

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

Marco Platania
 

You need to consider the DB in the APPC deployment, APPC doesn’t use the shared Maria DB cluster. Please see answer from Taka about redeploying APPC, it seems your installation didn’t go well.

 

Marco

 

From: Ferrero Marco Angelo <marco.ferrero@...>
Date: Thursday, August 29, 2019 at 11:14 AM
To: "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: 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: vDNS use case / issue with SO pub about APPC-READ

Taka Cho
 

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: ONAP deployment on AWS #casablanca

Marco Platania
 

Pritesh,

 

Keep in mind that the VNFs supported in ONAP need OpenStack. While ONAP can run in AWS (I know some community members did it), VNFs won’t, so you need to point SO to an OpenStack lab (or Devstack instance).

 

Marco

 

From: <onap-discuss@...> on behalf of Pritesh Gupta <gupta.pritesh@...>
Reply-To: "onap-discuss@..." <onap-discuss@...>, "gupta.pritesh@..." <gupta.pritesh@...>
Date: Thursday, August 29, 2019 at 10:49 AM
To: "onap-discuss@..." <onap-discuss@...>
Subject: [onap-discuss] ONAP deployment on AWS #casablanca

 

Hi Team,

I want to deploy ONAP on AWS to execute demos. I have tried Casablanca but facing some issue while deploying modules. 

If there some document that will help guide deployment of Dublin with all mandatory modules that are required to test vFW demo will be helpful.

Thanks,
Pritesh

ONAP deployment on AWS #casablanca

Pritesh Gupta
 

Hi Team,

I want to deploy ONAP on AWS to execute demos. I have tried Casablanca but facing some issue while deploying modules. 

If there some document that will help guide deployment of Dublin with all mandatory modules that are required to test vFW demo will be helpful.

Thanks,
Pritesh

Re: AWS EFS/NFS and Rancher 2.2 with EKS

Pritesh Gupta <gupta.pritesh@...>
 

Hi Michael,

I am deploying ONAP Casablanca on AWS using https://wiki.onap.org/display/DW/Cloud+Native+Deployment#CloudNativeDeployment-AmazonAWS link.

I have setup 1 master + 4 Nodes of Ubuntu 16.04 and EFS.

I was able to deploy some module but now when i am adding newer module it is facing issue related to space on EFS. Looking at EFS it doesnt seem to be space issue. When i remove few modules or retry by deleting module files for /docker-nfs directory it works. 

Can you please suggest some solution to get it fixed or some tuning that needs to be performed will be helpful.

Thanks,
Pritesh

Re: vCPE usecase: DHCP issue

Bartek Grzybowski
 

Hi

I'm Bartek and I cooperate with Michal on vCPE.

I managed to find the root cause of the issue which is security groups in Openstack. Although they are turned off for network and for port of the vBRG and vBNG VNF, neutron still applies anti spoofing rules in iptables:


Chain neutron-linuxbri-oab4fd8e9-1 (2 references)

(...)
2618  833K DROP       udp  --  *      *       0.0.0.0/0            0.0.0.0/0            udp spt:67 dpt:68 /* Prevent DHCP Spoofing by VM. */
(...)

"neutron-linuxbri-oab4fd8e9-1" is a chain associated with tap interface of vBNG which is proxying DHCPOFFERs to vBNG, thus this traffic is being dropped as "spoofed". Once  this rule is deleted vBRG gets it's lease from dhcp server. Nova probably cleans/adds those rules upon restart and  there's a brief period of time when the rules aren't applied and that reveals why the packets eventually "sneaked" by.

 

Anti spoofing rules shouldn't be applied as we have "port_security_enabled -> False", but there seems to be a bug: https://bugzilla.redhat.com/show_bug.cgi?id=1406263 fixed in this errata: https://access.redhat.com/errata/RHBA-2017:0314
In our Openstack version it should be fixed but for some reason it's still hitting us.

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

Steve Smokowski
 

Would need to confirm the distrobution of the model.  It appears to be missing here.  Can you query catalog db via command line or the API to verify that that model uuid exists?

 

Also it is running the scale out recipe, are you doing a scale out here?  Does your model contain the module model info to be scaled?

 

Thanks

 

-Steve

 

From: <onap-discuss@...> on behalf of "Mir, Adil Kamal" <adil_kamal.mir@...>
Reply-To: "onap-discuss@..." <onap-discuss@...>, "adil_kamal.mir@..." <adil_kamal.mir@...>
Date: Wednesday, August 28, 2019 at 5:12 PM
To: "onap-discuss@..." <onap-discuss@...>, "PLATANIA, MARCO" <platania@...>, D'Alessandro Alessandro Gerardo <alessandro.dalessandro@...>, "VENKATESH KUMAR, VIJAY" <vv770d@...>
Cc: "MALAKOV, YURIY" <ym9479@...>, Malinconico Aniello Paolo <a.malinconico@...>, Ferrero Marco Angelo <marco.ferrero@...>, "CHO, TAKAMUNE" <tc012c@...>
Subject: 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

CVE assigned for vulnerability in hibernate-validator

Krzysztof Opasiak
 

Hi,

This is a note and warning about a vulnerability in hibernate-validator
(CVE-2019-10219). The SafeHtml validator fails to properly sanitize
payloads. This could result in an XSS attack[1].

The vulnerability has not been fixed yet which means that even the
newest versions of hibernate-validator is vulnerable and all projects
that use it should consider it as a known vulnerability.

This is the bug that I've been mentioning for quite some time during
SECCOM meetings as discovered by one of my team members and reported to
Red Hat but couldn't share any details due to standard 90 embargo period.

I hope that the bug is going to be fixed soon and a simple upgrade of
this library should fix the issue.

Footnotes:
1 - https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2019-10219

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

Re: Minimal ONAP components required for VNF onboarding and deployment use case

Morgan Richomme
 

Hi kuldeep

it is surprising that aai is not part of the minimal config, it is the inventory.
On our side the min config was defined as core component and includes sdc (onboarding), aai (inventory), sdnc (preload, conf management at instantiation), so , dmaap, portal
then we defined small, medium,full to extend the configurations

vid is not mandatory but very helpful to understand the instantiation part and to instantiate without tools or robot scripts.
robot would also simplify lots of things for you and would provide you a feedback on the health of the different components (https://docs.onap.org/en/latest/submodules/integration.git/docs/docs_robot.html).

/Morgan

Le jeudi 29 août 2019 à 09:09 +0000, Kuldeep Singh Negi a écrit :

Hi Borislav,

 

We have done minimal ONAP Dublin deployment with following components - mariadb-galera, aaf, appc, cassandra, dmaap, multicloud, portal, sdc, sdnc, so 

If we need to do basic execution of onboarding and deploying a VNF, would we be needing any more components to deloy like aai, vid, robot etc.?

 

Thanks for your help.

 

Regards,

Kuldeep

 

::DISCLAIMER::
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects.
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

Re: Minimal ONAP components required for VNF onboarding and deployment use case

Borislav Glozman
 

You would need aai.

Rest depends what VNF you want to deploy.

If it is the demo vFW, you would need also vid and robot.

 

Thanks,

Borislav Glozman

O:+972.9.776.1988

M:+972.52.2835726

amdocs-a

Amdocs a Platinum member of ONAP

 

From: Kuldeep Singh Negi <KuldeepSinghN@...>
Sent: Thursday, August 29, 2019 12:09 PM
To: Borislav Glozman <Borislav.Glozman@...>; frank.obrien@...
Cc: onap-discuss@...; Mike Elliott <Mike.Elliott@...>; Prudence Au <Prudence.Au@...>
Subject: Minimal ONAP components required for VNF onboarding and deployment use case

 

Hi Borislav,

 

We have done minimal ONAP Dublin deployment with following components - mariadb-galera, aaf, appc, cassandra, dmaap, multicloud, portal, sdc, sdnc, so 

If we need to do basic execution of onboarding and deploying a VNF, would we be needing any more components to deloy like aai, vid, robot etc.?

 

Thanks for your help.

 

Regards,

Kuldeep

 

::DISCLAIMER::
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects.
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

This email and the information contained herein is proprietary and confidential and subject to the Amdocs Email Terms of Service, which you may review at https://www.amdocs.com/about/email-terms-of-service

Regarding accessing parameters in a VNF Tosca template from a parameter file

SIG ONAP
 

Hi,

I am trying to add a allowed address pairs list to the Connection Point in my template using { get_input: <ip-address-parameter> }  but I get an error message saying that "{ get_input: <ip-address-parameter> }" is not a string. I have defined the parameter in the inputs section under topology_templates section with type as type: string . Kindly, let me know if you need more information.

Thank you.
Regards.

Minimal ONAP components required for VNF onboarding and deployment use case

Kuldeep Singh Negi
 

Hi Borislav,

 

We have done minimal ONAP Dublin deployment with following components - mariadb-galera, aaf, appc, cassandra, dmaap, multicloud, portal, sdc, sdnc, so 

If we need to do basic execution of onboarding and deploying a VNF, would we be needing any more components to deloy like aai, vid, robot etc.?

 

Thanks for your help.

 

Regards,

Kuldeep

 

::DISCLAIMER::
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects.
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Re: [OOM] [CIA] [mariadb-galera]

Dmitry Puzikov
 

Hi, Mike,

Sounds good, let's sync up next week.
Thank you,

Best Regards,
Dmitry


From: Mike Elliott <Mike.Elliott@...>
Sent: Wednesday, August 28, 2019 18:19
To: onap-discuss@... <onap-discuss@...>; Puzikov Dmitry <dmitry.puzikov@...>; FREEMAN, BRIAN D <bf1936@...>; m.ptacek@... <m.ptacek@...>; Vitalie Dicusara <vitalied@...>; Jim Baker <jbaker@...>; 'Jessica Wagantall' <jwagantall@...>; dtimoney@... <dtimoney@...>; Mahendra Raghuwanshi <Mahendra.Raghuwanshi@...>; Amit Sinha <Amit.Sinha@...>; Prudence Au <Prudence.Au@...>
Cc: Klozik Martin <Martin.Klozik@...>; Paul.Vaduva@... <Paul.Vaduva@...>; STERN, ITTAY <ittay.stern@...>; 'Seshu m' <seshu.kumar.m@...>
Subject: Re: [onap-discuss] [OOM] [CIA] [mariadb-galera]
 

Hey Dmitry,

 

I’m very much onboard with the approach you just described. We can certainly migrate towards a smaller/multi-arch/better maintained image for the shared mariadb-galera cluster. Like Brian, not a big fan of forking but we can discuss and align on how to move to a new image.

 

I’m traveling today so was unable to attend OOM weekly.

Since this is not an immediate deliverable, are we good to sync up at next week’s meeting?

 

Thanks,

Mike.

 

From: <onap-discuss@...> on behalf of Dmitry Puzikov <dmitry.puzikov@...>
Reply-To: "onap-discuss@..." <onap-discuss@...>, "dmitry.puzikov@..." <dmitry.puzikov@...>
Date: Wednesday, August 28, 2019 at 5:29 AM
To: "FREEMAN, BRIAN D" <bf1936@...>, "m.ptacek@..." <m.ptacek@...>, onap-discuss <onap-discuss@...>, Mike Elliott <Mike.Elliott@...>, Vitalie Dicusara <vitalied@...>, Jim Baker <jbaker@...>, 'Jessica Wagantall' <jwagantall@...>, "dtimoney@..." <dtimoney@...>
Cc: Klozik Martin <Martin.Klozik@...>, "Paul.Vaduva@..." <Paul.Vaduva@...>, "STERN, ITTAY" <ittay.stern@...>, 'Seshu m' <seshu.kumar.m@...>
Subject: Re: [onap-discuss] [OOM] [CIA] [mariadb-galera]

 

Hi, all,

 

Brian, it's not that much selection of well maintained images if any.

Most of presented on DockerHub is quite old and moreover don't support multiple CPU archs.

 

Dan, I can not disagree with being cautious upon significant changes in front of code freeze :)

 

We're no way pushing OOM (or any other) team to switch to a new mariadb-galera image immediately.

It's just kick-off proposal to hear opinions, find out requirements and

understand potential side effects of such transition. It worth to point out that

it is safe to start working on new images until we actually change helm charts.

So now we can start preparing sources, setting up CI jobs, testing images.

Charts changing is the last step after building new image and its thorough testing.

I'm going to attend next OOM meeting to discuss further steps.

 

Thank you,

 

Best Regards,

Dmitry


From: onap-discuss@... <onap-discuss@...> on behalf of TIMONEY, DAN <dtimoney@...>
Sent: Tuesday, August 27, 2019 21:41
To: FREEMAN, BRIAN D <bf1936@...>; m.ptacek@... <m.ptacek@...>; onap-discuss <onap-discuss@...>; Puzikov Dmitry <dmitry.puzikov@...>; Mike Elliott <Mike.Elliott@...>; vitalied@... <vitalied@...>; Jim Baker <jbaker@...>; 'Jessica Wagantall' <jwagantall@...>
Cc: Klozik Martin <Martin.Klozik@...>; Paul.Vaduva@... <Paul.Vaduva@...>; STERN, ITTAY <ittay.stern@...>; 'Seshu m' <seshu.kumar.m@...>
Subject: Re: [onap-discuss] [OOM] [CIA] [mariadb-galera]

 

All,

 

I’d have no objection to up-revving in Frankfurt.  I’d rather not change versions in El Alto, though, given we’re a week and a half from code freeze (not that I anticipate code changes, but experience has taught me to be paranoid about these kinds of things).

 

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

 

From: "FREEMAN, BRIAN D" <bf1936@...>
Date: Tuesday, August 27, 2019 at 3:37 PM
To: "m.ptacek@..." <m.ptacek@...>, onap-discuss <onap-discuss@...>, Puzikov Dmitry <dmitry.puzikov@...>, Mike Elliott <Mike.Elliott@...>, "vitalied@..." <vitalied@...>, Jim Baker <jbaker@...>, 'Jessica Wagantall' <jwagantall@...>
Cc: Klozik Martin <Martin.Klozik@...>, "Paul.Vaduva@..." <Paul.Vaduva@...>, "STERN, ITTAY" <ittay.stern@...>, 'Seshu m' <seshu.kumar.m@...>, "TIMONEY, DAN" <dt5972@...>
Subject: RE: [OOM] [CIA] [mariadb-galera]

 

OOM team owns common mariadb.

 

I see common mariadb and VID as the helm charts that use this version.

 

adfinissygroup/k8s-mariadb-galera-centos

 

That would mean that vid, sdnc and so (both common mariadb) would be involved in concurring that up-reving is okay.

 

I am not sure when vid would move to the common mariadb.

 

All three have scripts to install schema’s and default data so there is a dependency that should be reviewed.

 

I would have thought that it would be better to find a good k8s pod source for mariadb rather than building our own but this is an OOM team call.

 

Brian

 

 

From: m.ptacek@... <m.ptacek@...>
Sent: Tuesday, August 27, 2019 3:30 PM
To: onap-discuss <onap-discuss@...>; Puzikov Dmitry <dmitry.puzikov@...>; Mike Elliott <Mike.Elliott@...>; vitalied@...; Jim Baker <jbaker@...>; FREEMAN, BRIAN D <bf1936@...>; 'Jessica Wagantall' <jwagantall@...>
Cc: Klozik Martin <Martin.Klozik@...>; Paul.Vaduva@...
Subject: RE: [OOM] [CIA] [mariadb-galera]

 

Hi Dmitry,

 

this looks like typical external dependency ONAP as platform should get rid of, but I am not sure if it’s up to OOM to decide this

image was introduced as a part of common galera cluster efforts OOM-758

 

but this looks more like platform related topic, honestly I don’t know if ONAP has any platform team responsible for such topics.

It might land-up in agenda of „LF guys“ as they hosts this project or „Integration“ team, which has probably the best E2E visibility

 

I hope you will get better answer ….

 

Thanks for raising such issues,

Michal

 

From: onap-discuss@... <onap-discuss@...> On Behalf Of Dmitry Puzikov
Sent: Monday, August 26, 2019 12:37 PM
To: onap-discuss <onap-discuss@...>
Cc: Klozik Martin <Martin.Klozik@...>; Paul.Vaduva@...; Mike Elliott <Mike.Elliott@...>
Subject: [onap-discuss] [OOM] [CIA] [mariadb-galera]

 

Hi, OOM team,

 

While working on ONAP image optimization as a CIA team

we noticed that some amount of third party images are used.

One of them is adfinissygroup/k8s-mariadb-galera-centos

which is used across whole ONAP.

According to OOM Helm charts version v002 is used.

In depth checking of adfinissygroup GitHub repo (https://github.com/adfinis-sygroup/openshift-mariadb-galera)

shows that MariaDB 10.1 is under the hood and this DB version remains the same regardless of

image version v002 or v004.

There's an issue OOM-1720 (maybe there are more) concerning about outdated DB.

Adfinissygroup repo seems not to be active for a long time and becoming more and more outdated.

 

Taking all said in account we propose to take over building of MariaDB-galera images under the OOM umbrella.

Steps to make it done:

1. Fork adfinissygroup repo

2. Make required modification (update dockerfile, update DB version)

3. Push updated sources to the ONAP repo.

Similar to `common` helm charts, e.g. `docker-common` (sub)repo might be created to host

such images sources.

4. Create CI job to build and push updated MariaDB image to ONAP registry.

5. Update Helm charts to use ONAP maintained MariaDB-galera version.

 

We actually already did first two steps and eager to continue with the rest.

Currently multiarch PoC images are available on DockerHub personal repo (https://hub.docker.com/r/zhabba/k8s-mariadb-galera-ubuntu)

and sources are available on GitHub personal repo (https://github.com/zhabba/openshift-mariadb-galera).

New k8s-mariadb-galera is based on Ubuntu and offers MariaDB v10.3 and v10.4 with the pretty the same

functionality as adfinissygroup predecessor with as twice as smaller image size (591MB vs. 1.09GB) and multiarch support.

Images are tested as standalone 3 nodes cluster and currently we're testing them as part of ONAP installation.

 

If you have any thoughts, comments, ideas or may be some additional test requirements let's discuss it in details.

 

Thank you,

 

Best Regards,

Dmitry

 

 

  

Image removed by sender.

This email and the information contained herein is proprietary and confidential and subject to the Amdocs Email Terms of Service, which you may review at https://www.amdocs.com/about/email-terms-of-service

Re: : testing Service instantiation with GR-API : FAILED

Rene Robert
 

Here attached are the SDNC logs

 

Test done on ONAP Dublin

 

 

De : onap-discuss@... [mailto:onap-discuss@...] De la part de Marco Platania
Envoyé : mercredi 28 août 2019 17:00
À : onap-discuss@...; SMOKOWSKI, STEVEN; ROBERT René TGI/OLN
Objet : Re: [onap-discuss]: testing Service instantiation with GR-API : FAILED

 

Rene,

 

Try to see if tickets SDNC-870 and SDNC-871 help. The error is reported by unassignBB; you go there when something else failed during instantiation. Look at the SDNC logs for more insights. If you are using SDNC cluster, check all the SDNC replicas as only one of them actually executes a given task.

 

Marco

 

 

From: <onap-discuss@...> on behalf of "SMOKOWSKI, STEVEN" <ss835w@...>
Reply-To: "onap-discuss@..." <onap-discuss@...>, "SMOKOWSKI, STEVEN" <ss835w@...>
Date: Wednesday, August 28, 2019 at 10:17 AM
To: "rene.robert@..." <rene.robert@...>, "onap-discuss@..." <onap-discuss@...>
Subject: Re: [onap-discuss]: testing Service instantiation with GR-API : FAILED

 

***Security Advisory: This Message Originated Outside of AT&T ***
Reference http://cso.att.com/EmailSecurity/IDSP.html for more information.

Appears to be SDNC infrastructure issue to me, please ask them for more details

 

Thanks

 

-Steve

 

From: "rene.robert@..." <rene.robert@...>
Date: Wednesday, August 28, 2019 at 10:08 AM
To: "SMOKOWSKI, STEVEN" <ss835w@...>, "onap-discuss@..." <onap-discuss@...>
Subject: [onap-discuss]: testing Service instantiation with GR-API : FAILED

 

Hello

I made a test with GR_API (using VID and using curl to SO)

 

Result : FAILED

 

service instance is declared in AAI but SO and SDNC seems to have some difficulties in their relationship

 


 

Any suggestion to troubleshoot the problem ?

 

 

Logo Orange

 

René Robert
«Open and Smart solutions for autOmating Network Services»
ORANGE/IMT/OLN/CNC/NARA/OSONS

 

Fixe : +33 2 96 07 39 29
Mobile : +33 6 74 78 68 43
rene.robert@...

 

 

 

 

 

_________________________________________________________________________________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
 
This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

Re: SDC APIs fail with 403 "Unauthorized Access" #sdc

Andreas Geissler
 

Hi Ofir,
no, I used the latest master of OOM, that means ElAlto.

In Dublin I never had this problem.

Best regards
Andreas

Re: [onap-tsc] Emergency Jenkins restart - NOW

Jessica Wagantall
 

Cleanup done and restart done too. 
I noticed we faced some Nexus server downtimes earlier today and some jobs because stuck trying to pull
dependencies and/or pushing logs and performing way slower than usual 
Those jobs were re-scheduled now.

Thanks so much 
Jess

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

I am getting some issues with Vexx nodes not being able to be properly remove themselves. 
I need to set Jenkins in quiet mode right now and do a restart + manual cleanup

Thanks so much for your patience
Jess

Updated Event: #doc Team (13:00 UTC) #doc #cal-invite

onap-discuss@lists.onap.org Calendar <onap-discuss@...>
 

#doc Team (13:00 UTC)

When:
Thursday, 22 August 2019
1:00pm to 2:00pm
(UTC+00:00) UTC
Repeats: Weekly on Thursday

Where:
https://zoom.us/j/907176290

Organizer: Sofia Wallin sofia.wallin@... Bridge: ONAP2

Description:

https://zoom.us/j/907176290
 
One tap mobile
+16465588656,,907176290# US (New York)
+16699006833,,907176290# US (San Jose)
 
Dial by your location
        +1 646 558 8656 US (New York)
        +1 669 900 6833 US (San Jose)
        855 880 1246 US Toll-free
        877 369 0926 US Toll-free
Meeting ID: 907 176 290
Find your local number: https://zoom.us/u/aedFyNdWz8

Emergency Jenkins restart - NOW

Jessica Wagantall
 

Dear ONAP

I am getting some issues with Vexx nodes not being able to be properly remove themselves. 
I need to set Jenkins in quiet mode right now and do a restart + manual cleanup

Thanks so much for your patience
Jess