Hi Jorge,
Appreciate your help, it indeed works so I can dump the
APPC-LCM-READ event now.
Thanks
Best Regards,
Bin Yang,Solution Engineering Team,Wind River
ONAP Multi-VIM/Cloud PTL
Direct +86,10,84777126Mobile +86,13811391682Fax +86,10,64398189
Skype: yangbincs993
From: HERNANDEZ-HERRERO, JORGE [mailto:jh1...@att.com]
Sent: Tuesday, September 11, 2018 11:01 PM
To: onap-discuss@lists.onap.org; Yang, Bin; DRAGOSH, PAM
Cc: MAHER, RANDA
Subject: RE: [onap-discuss][control-loop][policy][appc] Why policy does not
publish expected event to DMaaP for APPC restart action
Hello Bin,
Because you are creating it from an archetype, the configuration is not the
full blown one. Note that the
"topic": "APPC-LCM-READ",
"topicCommInfrastructure": "NOOP"
Uses a "noop" sink, therefore the output won't be put in the dmaap bus.
The change is simple, change the
"${POLICY_HOME}/config/amsterdam-controller.properties" - "noop" to "dmaap" or
"ueb" (will behave equivalently) .. use as a reference one of the ones that we
use for official installations as a reference.
It will help if you use the telemetry shell to explore runtime data and
configuration, simply type "telemetry" in the drools container, and then
navigate resources with "cd", see resources with "ls", and invoke "get"
commands to navigate it.
Note also that the first time you post a message to an anonymous dmaap topic,
it will create the topic, but the message won't be processed. The second
onwards would be.
Not sure about the message contents you are describing below, in theory the
Restart etc .. APPC messages have been significantly tested in conjunction with
the integration team.
Best regards,
Jorge
From: onap-discuss@lists.onap.org [mailto:onap-discuss@lists.onap.org] On
Behalf Of Yang Bin
Sent: Tuesday, September 11, 2018 4:57 AM
To: DRAGOSH, PAM ; onap-discuss@lists.onap.org
Cc: MAHER, RANDA
Subject: [onap-discuss][control-loop][policy][appc] Why policy does not publish
expected event to DMaaP for APPC restart action
Dear policy team,
Would you help me identify what is the root cause of following failure?
I come up with my own operational policy and provisioned to drools container,
however, it does not work as expected. The policy and the testing steps are
attached. The specific problems are:
# decoding the "topicSinks/recentEvents":
{
"alive": true,
"locked": false,
"recentEvents": [
"{\n \"body\": {\n\"input\": {\n \"common-header\":
{\n\"timestamp\": \"2018-09-11T09:38:32.486Z\",\n\"api-ver\":
\"2.00\",\n\"originator-id\":
\"8c1b8bd8-06f7-493f-8ed7-daaa4cc481bc\",\n\"request-id\":
\"8c1b8bd8-06f7-493f-8ed7-daaa4cc481bc\",\n\"sub-request-id\": \"1\",\n
\"flags\": {}\n },\n \"action\": \"Restart\",\n
\"action-identifiers\": {\n\"vnf-id\": \"zdfw1lb01lb01\"\n }\n
}\n },\n \"version\": \"2.0\",\n \"rpc-name\": \"restart\",\n
\"correlation-id\": \"8c1b8bd8-06f7-493f-8ed7-daaa4cc481bc-1\",\n \"type\":
\"request\"\n}"
],
"servers": [
"vm1.mr.simpledemo.openecomp.org"
],
"topic": "APPC-LCM-READ",
"topicCommInfrastructure": "NOOP"
},
==>
{
"body": {
"input": {
"common-header": {
"timestamp": "2018-09-11T08:43:10.499Z",
"api-ver": "2.00",
"originator-id": "8c1b8bd8-06f7-493f-8ed7-daaa4cc481bc",
"request-id": "8c1b8bd8-06f7-493f-8ed7-daaa4cc481bc",
"sub-request-id": "1",
"flags": {}
},
"action": "Restart",
"action-identifiers": {
"vnf-id": "zdfw1lb01lb01"
}
}
},