Re: [onap-discuss] [policy] CL Event Filed for Abated Alarms

2017-10-23 Thread fu.guangrong
Pam, That's exactly what we are doing at the moment, using the UUID class to generate the requestID. We are now sort of lost on how to pair the abated events with the onset ones with a proper key for the hash map. Anyways, we'll try to find a way to improve it. Thanks for you prompt r

Re: [onap-discuss] [policy] CL Event Filed for Abated Alarms

2017-10-23 Thread DRAGOSH, PAMELA L (PAM)
Guangrong, I would not use eventId – that is different and has different meaning. The requestID should be unique to the Control Loop and you can use UUID java class to generate a random one. You could simply use a HashTable in Drools memory and insert an object in order to retain state from ONS

Re: [onap-discuss] [policy] CL Event Filed for Abated Alarms

2017-10-23 Thread fu.guangrong
Pam, I have another question regarding the "requestID" in the control loop event. We are now using the "eventId" which is contained in the VES events as a key to judge whether the onset and abated alarms are in pair. To my understanding, if the alarms are in pair, we have to fill in

Re: [onap-discuss] [policy] CL Event Filed for Abated Alarms

2017-10-20 Thread DRAGOSH, PAMELA L (PAM)
Guangrong, Yes and no. The vnf-id is important in the ONSET as Policy has to lock that VNF to ensure multiple requests are not sent to it at the same time. The service-instance-id (and other subsequent A&AI information) helps performance in that Policy does not need to look that information up

[onap-discuss] [policy] CL Event Filed for Abated Alarms

2017-10-20 Thread fu.guangrong
Hi Pam, For the onset alarms, Policy requires the vnf-id and the service-instance-id in the CL event. How about the abated ones? Do we still have to fill in these two fields as well? I think the answer is negative because for the abated alarms, Policy does not use them to trigger any actio