Re: [onap-discuss] vFW Closed Loop - Operational Policy issues in Beijing #kubernetes #policy #drools #dcaegen2 #install #usecaseui
Hello, Thank you but this did not help. Mainly, I am getting errors regarding curl and brctl missing on the SINC VM: Making evel.o from evel.c /opt/VES/evel/evel-library/bldjobs/../code/evel_library/evel.c:36:23: fatal error: curl/curl.h: No such file or directory #include ^ compilation terminated. make: *** [/opt/VES/evel/evel-library/bldjobs/../code/evel_library/evel.o] Error 1 Adding system startup for /etc/init.d/vfirewall.sh ... /etc/rc0.d/K20vfirewall.sh -> ../init.d/vfirewall.sh /etc/rc1.d/K20vfirewall.sh -> ../init.d/vfirewall.sh /etc/rc6.d/K20vfirewall.sh -> ../init.d/vfirewall.sh /etc/rc2.d/S20vfirewall.sh -> ../init.d/vfirewall.sh /etc/rc3.d/S20vfirewall.sh -> ../init.d/vfirewall.sh /etc/rc4.d/S20vfirewall.sh -> ../init.d/vfirewall.sh /etc/rc5.d/S20vfirewall.sh -> ../init.d/vfirewall.sh vpp start/running, process 7759 tap-0 tap-1 ./v_firewall_init.sh: line 55: brctl: command not found ./v_firewall_init.sh: line 56: brctl: command not found ./v_firewall_init.sh: line 57: brctl: command not found ./v_firewall_init.sh: line 58: brctl: command not found ./v_firewall_init.sh: line 59: brctl: command not found ./v_firewall_init.sh: line 60: brctl: command not found br0: ERROR while getting interface flags: No such device br1: ERROR while getting interface flags: No such device Any hint on which ubuntu trusty version you are using? Best regards, -- Cristina Precup -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#12427): https://lists.onap.org/g/onap-discuss/message/12427 Mute This Topic: https://lists.onap.org/mt/25510782/21656 Mute #policy: https://lists.onap.org/mk?hashtag=policy=2740164 Mute #usecaseui: https://lists.onap.org/mk?hashtag=usecaseui=2740164 Mute #kubernetes: https://lists.onap.org/mk?hashtag=kubernetes=2740164 Mute #install: https://lists.onap.org/mk?hashtag=install=2740164 Mute #drools: https://lists.onap.org/mk?hashtag=drools=2740164 Group Owner: onap-discuss+ow...@lists.onap.org Unsubscribe: https://lists.onap.org/g/onap-discuss/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [onap-discuss] vFW Closed Loop - Operational Policy issues in Beijing #kubernetes #policy #drools #dcaegen2 #install #usecaseui
Hello Jorge, This time, the PDP healthcheck was Successful. However, regarding the ping from brmsgw: no, it cannot do name resolution and thus cannot ping the three pods (it's using their kubernetes cluster IPs, whereas for the pdp, policydb it does not): $ kubectl exec -it scapula-brmsgw-76cc87c68b-fjdfk -n onap -- bash -c "ping drools" PING drools.onap.svc.cluster.local (10.43.116.134) 56(84) bytes of data. ^C --- drools.onap.svc.cluster.local ping statistics --- 4 packets transmitted, 0 received, 100% packet loss, time 3016ms $ kubectl exec -it scapula-brmsgw-76cc87c68b-fjdfk -n onap -- bash -c "ping nexus" PING nexus.onap.svc.cluster.local (10.43.77.23) 56(84) bytes of data. ^C --- nexus.onap.svc.cluster.local ping statistics --- 2 packets transmitted, 0 received, 100% packet loss, time 1007ms $ kubectl exec -it scapula-brmsgw-76cc87c68b-fjdfk -n onap -- bash -c "ping message-router" PING message-router.onap.svc.cluster.local (10.43.130.167) 56(84) bytes of data. ^C --- message-router.onap.svc.cluster.local ping statistics --- 4 packets transmitted, 0 received, 100% packet loss, time 3022ms $ kubectl exec -it scapula-brmsgw-76cc87c68b-fjdfk -n onap -- bash -c "ping pdp" PING pdp.onap.svc.cluster.local (10.42.8.26) 56(84) bytes of data. 64 bytes from scapula-pdp-0.pdp.onap.svc.cluster.local (10.42.8.26): icmp_seq=1 ttl=62 time=0.620 ms 64 bytes from scapula-pdp-0.pdp.onap.svc.cluster.local (10.42.8.26): icmp_seq=2 ttl=62 time=0.652 ms ^C --- pdp.onap.svc.cluster.local ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 1000ms rtt min/avg/max/mdev = 0.620/0.636/0.652/0.016 ms $ kubectl exec -it scapula-brmsgw-76cc87c68b-fjdfk -n onap -- bash -c "ping policydb" PING policydb.onap.svc.cluster.local (10.42.8.12) 56(84) bytes of data. 64 bytes from wsalpha-worker-1.x.com (10.42.8.12): icmp_seq=1 ttl=62 time=1.76 ms 64 bytes from wsalpha-worker-1.x.com (10.42.8.12): icmp_seq=2 ttl=62 time=0.626 ms 64 bytes from wsalpha-worker-1.x.com (10.42.8.12): icmp_seq=3 ttl=62 time=0.721 ms ^C --- policydb.onap.svc.cluster.local ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2000ms rtt min/avg/max/mdev = 0.626/1.036/1.762/0.515 ms As for the Openstack issue: indeed, I made sure the names differ quite a lot (i.e., the generic-vnf-name is not a substring of the vnf-name). The stack has been deployed and this time there is traffic flowing. I had to switch to demo_artifacts_version=1.3.0 in the preload as I see that the 1.2.1 has been removed. However, this gives a build error in the SINC VM: Making evel.o from evel.c /opt/VES/evel/evel-library/bldjobs/../code/evel_library/evel.c: In function 'evel_free_event': /opt/VES/evel/evel-library/bldjobs/../code/evel_library/evel.c:461:7: warning: implicit declaration of function 'evel_free_hrtbt_field' [-Wimplicit-function-declaration] evel_free_hrtbt_field((EVENT_HEARTBEAT_FIELD *)evt_ptr); ^ Making metadata.o from metadata.c Making ring_buffer.o from ring_buffer.c Making double_list.o from double_list.c Making hashtable.o from hashtable.c Making evel_event.o from evel_event.c /opt/VES/evel/evel-library/bldjobs/../code/evel_library/evel_event.c: In function 'evel_json_encode_eventtype': /opt/VES/evel/evel-library/bldjobs/../code/evel_library/evel_event.c:591:11: warning: implicit declaration of function 'evel_json_encode_voice_quality' [-Wimplicit-function-declaration] evel_json_encode_voice_quality(jbuf, (EVENT_VOICE_QUALITY *)event); ^ /opt/VES/evel/evel-library/bldjobs/../code/evel_library/evel_event.c:595:11: warning: implicit declaration of function 'evel_json_encode_threshold_cross' [-Wimplicit-function-declaration] evel_json_encode_threshold_cross(jbuf, (EVENT_THRESHOLD_CROSS *)event); ^ Making evel_fault.o from evel_fault.c Making evel_mobile_flow.o from evel_mobile_flow.c /opt/VES/evel/evel-library/bldjobs/../code/evel_library/evel_mobile_flow.c: In function 'evel_json_encode_mobile_flow': /opt/VES/evel/evel-library/bldjobs/../code/evel_library/evel_mobile_flow.c:965:7: warning: implicit declaration of function 'evel_throttle_suppress_nv_pair' [-Wimplicit-function-declaration] if (!evel_throttle_suppress_nv_pair(jbuf->throttle_spec, ^ Making evel_option.o from evel_option.c /opt/VES/evel/evel-library/bldjobs/../code/evel_library/evel_option.c: In function 'evel_force_option_intheader': /opt/VES/evel/evel-library/bldjobs/../code/evel_library/evel_option.c:393:18: warning: assignment discards 'const' qualifier from pointer target type [enabled by default] option->object = value; ^ /opt/VES/evel/evel-library/bldjobs/../code/evel_library/evel_option.c: In function 'evel_set_option_intheader': /opt/VES/evel/evel-library/bldjobs/../code/evel_library/evel_option.c:426:20: warning: assignment discards 'const' qualifier from pointer target type [enabled by default] option->object = value;
Re: [onap-discuss] vFW Closed Loop - Operational Policy issues in Beijing #kubernetes #policy #drools #dcaegen2 #install #usecaseui
Dear Jorge, This really did fix my problem for Policy upload. Thank you for that. However, it seems that after the update, the SINC vFW VMs get created on Openstack, they have no errors in the logs, the networks get created, but then all of them get deleted from Openstack. Any idea what it could be? It seems to me like this is the equivalent of an automatic deletion of the VF SINC Module. Best regards, -- Cristina Precup -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#12421): https://lists.onap.org/g/onap-discuss/message/12421 Mute This Topic: https://lists.onap.org/mt/25510782/21656 Mute #policy: https://lists.onap.org/mk?hashtag=policy=2740164 Mute #usecaseui: https://lists.onap.org/mk?hashtag=usecaseui=2740164 Mute #kubernetes: https://lists.onap.org/mk?hashtag=kubernetes=2740164 Mute #install: https://lists.onap.org/mk?hashtag=install=2740164 Mute #drools: https://lists.onap.org/mk?hashtag=drools=2740164 Group Owner: onap-discuss+ow...@lists.onap.org Unsubscribe: https://lists.onap.org/g/onap-discuss/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [onap-discuss] vFW Closed Loop - Operational Policy issues in Beijing #kubernetes #policy #drools #dcaegen2 #install #usecaseui
Hello Jorge, Thank you for pointing me in the right direction. I did go through the wiki page that you are mentioning. Here is the overview in short: - Healthcheck: PDP and PAP are unreachable - Policy healthcheck fails - There is no default group in the PDP Tab of the Policy UI - brmsgw cannot ping nexus, drools and message-router I understand that the POLICY-1097 fix has been applied in the Casablanca release. Would you suggest taking the changes as a patch into Beijing? What would be the recommended approach here? Best regards, -- Cristina Precup -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#12381): https://lists.onap.org/g/onap-discuss/message/12381 Mute This Topic: https://lists.onap.org/mt/25510782/21656 Mute #policy: https://lists.onap.org/mk?hashtag=policy=2740164 Mute #usecaseui: https://lists.onap.org/mk?hashtag=usecaseui=2740164 Mute #kubernetes: https://lists.onap.org/mk?hashtag=kubernetes=2740164 Mute #install: https://lists.onap.org/mk?hashtag=install=2740164 Mute #drools: https://lists.onap.org/mk?hashtag=drools=2740164 Group Owner: onap-discuss+ow...@lists.onap.org Unsubscribe: https://lists.onap.org/g/onap-discuss/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [onap-discuss] vFW Closed Loop - Operational Policy issues in Beijing #kubernetes #policy #drools #dcaegen2 #install #usecaseui
Hello, Thank you for the reference. I did do the onboarding step mentioned here, making sure to replace the field with the correct PG model-invariant-id in the posh-policies.sh script. However, I don't think this script actually does the onboarding in my case: kubectl exec -it scapula-pap-5bf5f48d7b-v7fld -c pap -n onap -- bash -c "export PRELOAD_POLICIES=true; /home/policy/push-policies.sh" Upload BRMS Param Template --2018-09-11 11:32:53-- https://git.onap.org/policy/drools-applications/plain/controlloop/templates/archetype-cl-amsterdam/src/main/resources/archetype-resources/src/main/resources/__closedLoopControlName__.drl Resolving git.onap.org (git.onap.org)... 198.145.29.92 Connecting to git.onap.org (git.onap.org)|198.145.29.92|:443... connected. HTTP request sent, awaiting response... 200 OK Length: 58366 (57K) [text/plain] Saving to: 'cl-amsterdam-template.drl' 100%[==>] 58,366 193KB/s in 0.3s 2018-09-11 11:32:54 (193 KB/s) - 'cl-amsterdam-template.drl' saved [58366/58366] * Hostname was NOT found in DNS cache * Trying 10.42.10.50... * Connected to pdp (10.42.10.50) port 8081 (#0) > POST /pdp/api/policyEngineImport HTTP/1.1 > User-Agent: curl/7.35.0 > Host: pdp:8081 > Accept: text/plain > ClientAuth: cHl0aG9uOnRlc3Q= > Authorization: Basic dGVzdHBkcDphbHBoYTEyMw== > Environment: TEST > Content-Length: 58757 > Expect: 100-continue > Content-Type: multipart/form-data; > boundary=110622b19dc01d62 > * Connection #0 to host pdp left intact PPRELOAD_POLICIES is true Create BRMSParam Operational Policies Create BRMSParamvFirewall Policy * Hostname was NOT found in DNS cache * Trying 10.42.10.50... * Connected to pdp (10.42.10.50) port 8081 (#0) > PUT /pdp/api/createPolicy HTTP/1.1 > User-Agent: curl/7.35.0 > Host: pdp:8081 > Content-Type: application/json > Accept: text/html > ClientAuth: cHl0aG9uOnRlc3Q= > Authorization: Basic dGVzdHBkcDphbHBoYTEyMw== > Environment: TEST > Content-Length: 1309 > Expect: 100-continue > * Connection #0 to host pdp left intact PCreate BRMSParamvDNS Policy * Hostname was NOT found in DNS cache * Trying 10.42.10.50... * Connected to pdp (10.42.10.50) port 8081 (#0) > PUT /pdp/api/createPolicy HTTP/1.1 > User-Agent: curl/7.35.0 > Host: pdp:8081 > Content-Type: application/json > Accept: text/html > ClientAuth: cHl0aG9uOnRlc3Q= > Authorization: Basic dGVzdHBkcDphbHBoYTEyMw== > Environment: TEST > Content-Length: 1148 > Expect: 100-continue > * Connection #0 to host pdp left intact PCreate BRMSParamVOLTE Policy * Hostname was NOT found in DNS cache * Trying 10.42.10.50... * Connected to pdp (10.42.10.50) port 8081 (#0) > PUT /pdp/api/createPolicy HTTP/1.1 > User-Agent: curl/7.35.0 > Host: pdp:8081 > Content-Type: application/json > Accept: text/html > ClientAuth: cHl0aG9uOnRlc3Q= > Authorization: Basic dGVzdHBkcDphbHBoYTEyMw== > Environment: TEST > Content-Length: 1140 > Expect: 100-continue > * Connection #0 to host pdp left intact PCreate BRMSParamvCPE Policy * Hostname was NOT found in DNS cache * Trying 10.42.10.50... * Connected to pdp (10.42.10.50) port 8081 (#0) > PUT /pdp/api/createPolicy HTTP/1.1 > User-Agent: curl/7.35.0 > Host: pdp:8081 > Content-Type: application/json > Accept: text/html > ClientAuth: cHl0aG9uOnRlc3Q= > Authorization: Basic dGVzdHBkcDphbHBoYTEyMw== > Environment: TEST > Content-Length: 1139 > Expect: 100-continue > * Connection #0 to host pdp left intact PCreate MicroService Config Policies Create MicroServicevFirewall Policy * Hostname was NOT found in DNS cache * Trying 10.42.10.50... * Connected to pdp (10.42.10.50) port 8081 (#0) > PUT /pdp/api/createPolicy HTTP/1.1 > User-Agent: curl/7.35.0 > Host: pdp:8081 > Content-Type: application/json > Accept: text/plain > ClientAuth: cHl0aG9uOnRlc3Q= > Authorization: Basic dGVzdHBkcDphbHBoYTEyMw== > Environment: TEST > Content-Length: 1689 > Expect: 100-continue > * Connection #0 to host pdp left intact PCreate MicroServicevDNS Policy * Hostname was NOT found in DNS cache * Trying 10.42.10.50... * Connected to pdp (10.42.10.50) port 8081 (#0) > PUT /pdp/api/createPolicy HTTP/1.1 > User-Agent: curl/7.35.0 > Host: pdp:8081 > Content-Type: application/json > Accept: text/plain > ClientAuth: cHl0aG9uOnRlc3Q= > Authorization: Basic dGVzdHBkcDphbHBoYTEyMw== > Environment: TEST > Content-Length: 1306 > Expect: 100-continue > * Connection #0 to host pdp left intact PCreate MicroServicevCPE Policy * Hostname was NOT found in DNS cache * Trying 10.42.10.50... * Connected to pdp (10.42.10.50) port 8081 (#0) > PUT /pdp/api/createPolicy HTTP/1.1 > User-Agent: curl/7.35.0 > Host: pdp:8081 > Content-Type: application/json > Accept: text/plain > ClientAuth: cHl0aG9uOnRlc3Q= > Authorization: Basic dGVzdHBkcDphbHBoYTEyMw== > Environment: TEST > Content-Length: 1640 > Expect: 100-continue > * Connection #0 to host pdp left intact PCreating Decision Guard policy * Hostname was NOT found in
[onap-discuss] vFW Closed Loop - Operational Policy issues in Beijing #kubernetes #policy #drools #dcaegen2 #install #usecaseui
Dear community,
I am trying to upload the Operational Policy for the Closed Loop part of the
virtual Firewall use case (step 2 of Close Loop in
https://wiki.onap.org/display/DW/vFWCL+instantiation%2C+testing%2C+and+debuging).
However, there is no Policy after performing the upload step with
update-vfw-op-policy.sh:
$ sh update-vfw-op-policy.sh localhost 30220 30221
3a35d839-82cc-442a-bcff-92d5d97d6a1f
Removing the vFW Policy from PDP..
* Trying ::1...
* TCP_NODELAY set
* Connected to localhost (::1) port 30220 (#0)
Handling connection for 30220
> DELETE /pdp/api/deletePolicy HTTP/1.1
> Host: localhost:30220
> User-Agent: curl/7.54.0
> Content-Type: application/json
> Accept: text/plain
> ClientAuth: cHl0aG9uOnRlc3Q=
> Authorization: Basic dGVzdHBkcDphbHBoYTEyMw==
> Environment: TEST
> Content-Length: 128
>
* upload completely sent off: 128 out of 128 bytes
* Connection #0 to host localhost left intact
P
Updating vFW Operational Policy ..
* Trying ::1...
* TCP_NODELAY set
* Connected to localhost (::1) port 30220 (#0)
> PUT /pdp/api/updatePolicy HTTP/1.1
> Host: localhost:30220
> User-Agent: curl/7.54.0
Handling connection for 30220
> Content-Type: application/json
> Accept: text/plain
> ClientAuth: cHl0aG9uOnRlc3Q=
> Authorization: Basic dGVzdHBkcDphbHBoYTEyMw==
> Environment: TEST
> Content-Length: 1328
> Expect: 100-continue
>
* Connection #0 to host localhost left intact
P
Pushing the vFW Policy ..
* Trying ::1...
* TCP_NODELAY set
* Connected to localhost (::1) port 30220 (#0)
Handling connection for 30220
> PUT /pdp/api/pushPolicy HTTP/1.1
> Host: localhost:30220
> User-Agent: curl/7.54.0
> Content-Type: application/json
> Accept: text/plain
> ClientAuth: cHl0aG9uOnRlc3Q=
> Authorization: Basic dGVzdHBkcDphbHBoYTEyMw==
> Environment: TEST
> Content-Length: 99
>
* upload completely sent off: 99 out of 99 bytes
* Connection #0 to host localhost left intact
P
Restarting PDP-D ..
[drools-pdp-controllers]
L []: Stopping Policy Management... Policy Management (pid=3306) is
stopping... Policy Management has stopped.
[drools-pdp-controllers]
L []: Policy Management (pid 3711) is running
PDP-D amsterdam maven coordinates ..
* Trying ::1...
* TCP_NODELAY set
* Connected to localhost (::1) port 30221 (#0)
* Server auth using Basic with user '@1b3rt'
> GET /policy/pdp/engine/controllers/amsterdam/drools HTTP/1.1
> Host: localhost:30221
> Authorization: Basic QDFiM3J0OjMxbnN0MzFu
> User-Agent: curl/7.54.0
> Accept: */*
>
Handling connection for 30221
< HTTP/1.1 200 OK
< Date: Mon, 10 Sep 2018 13:31:31 GMT
< Content-Type: application/json
< Content-Length: 231
< Server: Jetty(9.3.24.v20180605)
<
{ [231 bytes data]
* Connection #0 to host localhost left intact
{
"alive": false,
"artifactId": "NO-ARTIFACT-ID",
"brained": false,
"canonicalSessionNames": [],
"container": null,
"groupId": "NO-GROUP-ID",
"locked": false,
"recentSinkEvents": [],
"recentSourceEvents": [],
"sessionNames": [],
"version": "NO-VERSION"
}
PDP-D control loop updated ..
* Trying ::1...
* TCP_NODELAY set
* Connected to localhost (::1) port 30221 (#0)
* Server auth using Basic with user '@1b3rt'
Handling connection for 30221
> GET
> /policy/pdp/engine/controllers/amsterdam/drools/facts/closedloop-amsterdam/org.onap.policy.controlloop.Params
> HTTP/1.1
> Host: localhost:30221
> Authorization: Basic QDFiM3J0OjMxbnN0MzFu
> User-Agent: curl/7.54.0
> Accept: */*
>
< HTTP/1.1 200 OK
< Date: Mon, 10 Sep 2018 13:31:32 GMT
< Content-Type: application/json
< Content-Length: 2
< Server: Jetty(9.3.24.v20180605)
<
{ [2 bytes data]
* Connection #0 to host localhost left intact
[]
Furthermore, the policy portal does not have any policies in it.
Here is the output of the drools healthcheck:
CURL GET http://10.42.1.8:6969/healthcheck (see postman)
{
"healthy": false,
"details": [
{
"name": "PDP-D",
"url": "self",
"healthy": true,
"code": 200,
"message": "alive"
},
{
"name": "PAP",
"url": "http://pap:9091/pap/test;,
"healthy": false,
"code": 0,
"message": null
},
{
"name": "PDP",
"url": "http://pdp:8081/pdp/test;,
"healthy": false,
"code": 0,
"message": null
}
]
}
I understand that the steps have changed in Beijing, and have therefore
switched to the Before Installing Policies and Install Policies steps from this
wiki https://wiki.onap.org/display/DW/Policy+on+OOM.
In my case, it seems that the service name resolution for brmsgw does not work
for nexus, drools and message-router. The situation is identical to the one
reported here:
https://lists.onap.org/g/onap-discuss/message/12074?p=,,,20,0,0,0::relevance,,%23policy,20,2,0,2497.
Are there any instructions on how to deal with this issue? What is the
password for policy user with
Re: [onap-discuss] PNDA - DCAE:DMaaP integration - inquiry on data production and consumption #dmaap
Thank you, Sunil! Best regards -- Cristina Precup -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#12192): https://lists.onap.org/g/onap-discuss/message/12192 Mute This Topic: https://lists.onap.org/mt/24973111/21656 Mute #dmaap: https://lists.onap.org/mk?hashtag=dmaap=2740164 Group Owner: onap-discuss+ow...@lists.onap.org Unsubscribe: https://lists.onap.org/g/onap-discuss/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [onap-discuss] PNDA - DCAE:DMaaP integration - inquiry on data production and consumption #dmaap
Hello Unnava, Sounds great! Do you have a commit reference for this change? Best regards, -- Cristina Precup -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#12184): https://lists.onap.org/g/onap-discuss/message/12184 Mute This Topic: https://lists.onap.org/mt/24973111/21656 Mute #dmaap: https://lists.onap.org/mk?hashtag=dmaap=2740164 Group Owner: onap-discuss+ow...@lists.onap.org Unsubscribe: https://lists.onap.org/g/onap-discuss/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[onap-discuss] PNDA - DCAE:DMaaP integration - inquiry on data production and consumption #dmaap
We are working on integrating PNDA applications with the DMaaP component in ONAP:DCAE (https://jira.onap.org/browse/DCAEGEN2-371). In a first phase, we would like to cross-post topics between PNDA and DMaaP and process the streams of messages. For this, we have created a test environment where we are posting directly to the Kafka broker underneath the DMaaP component. We understand that the DMaaP component is meant to be used through its REST endpoint. As pointed by Donald in the Story above, we are concerned about the performance impact of switching to the DMaaP REST endpoint instead of directly using a Kafka endpoint. Could you detail your view on the matter of performance and what the preferred method would be? Alternatively, we propose having a Kafka endpoint exposed as a NodePort or running a Kubernetes container as a Kafka forwarder. Looking forward to your feedback! Best regards, -- Cristina Precup -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#12070): https://lists.onap.org/g/onap-discuss/message/12070 Mute This Topic: https://lists.onap.org/mt/24973111/21656 Mute #dmaap: https://lists.onap.org/mk?hashtag=dmaap=2740164 Group Owner: onap-discuss+ow...@lists.onap.org Unsubscribe: https://lists.onap.org/g/onap-discuss/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[onap-discuss] #dcaegen2 - Development and Integration of TCA and PNDA Applications with DCAE:DMaaP
Hello, We are interested in understanding what kind of applications would be of interest for the DCAE:DMaaP - PNDA integration. Could you provide some pointers for the state and plans of development for the TCA? It would help to know more on whether it is intended to have the current TCA implementation (https://github.com/onap/dcaegen2-analytics-tca) replicated as a CDAP-independent development and where this process stands. Thank you! Best regards, — Cristina Precup -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#11785): https://lists.onap.org/g/onap-discuss/message/11785 Mute This Topic: https://lists.onap.org/mt/24238621/21656 Mute #dcaegen2: https://lists.onap.org/mk?hashtag=dcaegen2=2740164 Group Owner: onap-discuss+ow...@lists.onap.org Unsubscribe: https://lists.onap.org/g/onap-discuss/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
