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 response.
Guangrong
Original Mail
Sender: <[email protected]>;
To: fuguangrong10144542;
CC: <[email protected]>;tianshiwei10223543;
Date: 2017/10/23 17:53
Subject: Re: [policy] CL Event Filed for Abated Alarms
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 ONSET to ABATED.
Thanks,
Pam
From: "[email protected]" <[email protected]>
Date: Monday, October 23, 2017 at 5:14 AM
To: "DRAGOSH, PAMELA L (PAM)" <[email protected]>
Cc: "[email protected]" <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [policy] CL Event Filed for Abated Alarms
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 the same request ID into the
control loop event. What I'm not sure about is whether the event ID in the VES
events is globally unique which means even for the onset and abated alarms
pairs, they has different event IDs. If so, do you have any suggestions on how
to generate and maintain the request ID?
I remember you have ever said that since we are using drools, it's very simple
for us to have the request IDs maintained. Could you please give us more
details?
Thanks.
Guangrong
Original Mail
Sender: <[email protected]>;
To: fuguangrong10144542;
CC: <[email protected]>;tianshiwei10223543;
Date: 2017/10/20 21:33
Subject: Re: [policy] CL Event Filed for Abated Alarms
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 to make the call to VFC.
For ABATED, we are probably ok with NOT adding any A&AI details. As long as the
controlLoopControlName and RequestID match the previous ONSET, then we can tie
them together and finish the control loop.
Thanks,
Pam
From: "[email protected]" <[email protected]>
Date: Friday, October 20, 2017 at 9:12 AM
To: "DRAGOSH, PAMELA L (PAM)" <[email protected]>
Cc: "[email protected]" <[email protected]>,
"[email protected]" <[email protected]>
Subject: [policy] CL Event Filed for Abated Alarms
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 actions on VMs. They're just a certain
kind of confirmation. Is that right?
Regards,
Guangrong
_______________________________________________
onap-discuss mailing list
[email protected]
https://lists.onap.org/mailman/listinfo/onap-discuss
