Hi, As far as I understand we have a base agreement that both specs are appropriate and either of that two features are shifted to Mitaka cycle.
Gordon probably that question to you: Are we going to create a new folder in spec's dir for next cycle, or we continue discussing "new" specs as part of liberty? And the second one: are we going to create special rep for AODH specs or ceilometer-specs is ok for all new projects? Thank you in advance, Igor Degtiarov Software Engineer Mirantis Inc. www.mirantis.com On Fri, Aug 7, 2015 at 10:59 AM, Ryota Mibu <[email protected]> wrote: > 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:[email protected]] > > 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: > [email protected]?subject:unsubscribe > > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > > -- > > -- > > gord > > > > > > > > > __________________________________________________________________________ > > OpenStack Development Mailing List (not for usage questions) > > Unsubscribe: > [email protected]?subject:unsubscribe > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
