Open Stack

Hi,


Sorry for my late response and my absent in weekly meetings...

I'm not sure whether I captured your idea correctly, but I prefer the second approach now.

I agreed the point Igor and liusheng mentioned that the second approach enables end users to have configurable expire-time.

In another point of view, the first approach may affect pipeline performance since it have to keep event sequence state or have to access DB for state querying when each event received. This is just my concern, but I think event pipeline should be simplest and limited to have only common features between event data storage, event alarming and other receiver like audit system.


Thanks,
Ryota

> -----Original Message-----
> From: liusheng [mailto:liusheng1175 at 126.com]
> Sent: Wednesday, August 05, 2015 1:12 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [Ceilometer][AODH] Timeout Event Alarms
> 
> Hi,
> 
> Maybe the event transformer is needed in some use cases to generate new events or do transformations like the samples
> handling.  but for this timeout event alarming requirement,  the 'timeout' of alarms will be various, it not a good idea
> of changing event_pipeline.yaml to generate new events based on events timeout when we need an event-timeout alarm. and
> also, the access of event pipeline definitions to users is inadvisable. I personally think it'd better to implement the
> second option and based on Ryota's proposal.
> 
> Best Regards
> Liusheng
> 
> 
> 在 2015/8/5 3:36, gord chung 写道:
> 
> 
> 	hi Igor,
> 
> 	i would suggest you go with second option as i believe your implementation will overlap and reuse some of the
> functionality Ryota would code for his alarm spec [1]. also, since Aodh is working on an independent release cycle, it'll
> give you some more time as i don't think we'd be able to get this into Liberty if we went the pipeline route.
> 
> 	[1] http://specs.openstack.org/openstack/ceilometer-specs/specs/liberty/event-alarm-evaluator.html
> 
> 
> 	On 04/08/2015 10:00 AM, Igor Degtiarov wrote:
> 
> 
> 		Hi folks,
> 
> 
> 		On our meatup we agreed to add timeout event alarms [1](Event-Base Alarming part).
> 		In ToDo task "Сhoose the optimal way for timeout alerting implementation"
> 
> 		Now we have two proposition for implementation:
> 
> 		 - first is to add timeout param in event pipeline (transformer part) [2]
> 		   -- weakness of this approach is that we cannot allow user change config files, so only administrator
> will be able to set rules for timeout events alarms, and that is not what we are expecting from alarms.
> 
> 		 - second is additional optional parameters in event alarms description like sequence of required events
> and timeout threshold. Event alarm evaluator looks thru getting events and evaluates alarm if even one event from required
> sequence isn't received in set "timeout".[3]
> 
> 
> 		It seems that second approach is better it doesn't have restrictions for end user.
> 
> 		Hope for your help in choosing optimal way for implementation.
> 		(In specs review there is silence now)
> 
> 
> 		[1] https://wiki.openstack.org/wiki/Meetings/Ceilometer/Liberty_Virtual_Mid-Cycle
> 		[2] https://review.openstack.org/#/c/162167
> 		[3] https://review.openstack.org/#/c/199005
> 
> 
> 		Igor Degtiarov
> 		Software Engineer
> 		Mirantis Inc.
> 		www.mirantis.com
> 
> 
> 
> 		__________________________________________________________________________
> 		OpenStack Development Mailing List (not for usage questions)
> 		Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> 		http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> 	--
> 	--
> 	gord
> 
> 
> 
> 	__________________________________________________________________________
> 	OpenStack Development Mailing List (not for usage questions)
> 	Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> 	http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>